С выходом VMware Cloud Foundation 9.0 произошёл переломный момент в подходе к связыванию vCenter. VCF 9 вводит принципиально новую архитектуру единого входа (Single Sign-On) для всех компонентов частного облака, устраняя необходимость в классическом ELM для объединения серверов vCenter. Фактически, в окружениях на базе VCF 9 Enhanced Linked Mode более не используется для объединения vCenter в единый домен SSO...

Diagnostics for VMware Cloud Foundation — это централизованная платформа, которая отслеживает общее состояние работы программного стека VMware Cloud Foundation (VCF). Это платформа самообслуживания, помогающая анализировать и устранять неполадки компонентов VMware Cloud Foundation, включая vCenter, ESX, vSAN, а также возможностей, таких как vSphere vMotion, снапшоты, развертывание виртуальных машин (VM provisioning), и других аспектов, включая уведомления безопасности и сертификаты. Администратор инфраструктуры может использовать диагностические данные, чтобы контролировать текущее состояние своей среды.

Диагностические результаты (Findings)

Результаты диагностики, которые ранее предоставлялись через Skyline Advisor и Skyline Health Diagnostics, теперь доступны клиентам VCF и vSphere Foundation (VVF) в рамках продукта VCF Operations. Результаты приоритизируются по:

• Часто встречающимся проблемам, выявленным службой технической поддержки Broadcom.
• Вопросам, поднятым в рамках анализа эскалаций (post escalation review).
• Уязвимостям безопасности.
• Проблемам, выявленным инженерными командами Broadcom.
• Рекомендациям от клиентов.

В последнем релизе VCF Operations выпущено 114 новых диагностических результатов (Findings):

• 83 — основаны на часто встречающихся проблемах.
• 15 — по результатам анализа эскалаций.
• 14 — связаны с уязвимостями безопасности (VMSA).
• 2 — по запросам клиентов.

Из них:

• 62 результата состояния (Health Findings) — эквивалентны результатам Skyline Advisor и автоматически проверяются каждые 4 часа.
• 52 результата на основе логов (Log-based Findings) — эквивалентны Skyline Health Diagnostics и инициируются вручную через интерфейс конфигурации.

Эти новые находки включены в VCF Operations 9.0.1 (Release Notes). Давайте посмотрим на некоторые примеры этих результатов.

Уязвимости безопасности

В VMSA-2025-0010 описана уязвимость аутентифицированного выполнения команд в VMware vCenter Server (CVE-2025-41225) и уязвимость межсайтового скриптинга (XSS) в VMware ESXi и vCenter Server (CVE-2025-41228). Злоумышленник, обладающий привилегиями для создания или изменения тревог (alarms) и выполнения действий сценариев (script action), может воспользоваться данной уязвимостью для выполнения произвольных команд на сервере vCenter.

Злоумышленник, имеющий сетевой доступ к странице входа определённого хоста ESX или к путям URL сервера vCenter Server, может использовать эту уязвимость для кражи cookie-файлов или перенаправления пользователей на вредоносные веб-сайты. Эта уязвимость устранена в vCenter Server 8.0 Update 3e.

Анализ после эскалации (Post Escalation Review)

Техническая поддержка Broadcom внедрила процесс Post Escalation Review, в рамках которого критические обращения анализируются для предотвращения подобных инцидентов в будущем. Одним из результатов такого анализа является создание новых диагностических результатов.

Например, KB #370670:

Хосты ESX могут терять подключение к vCenter из-за чрезмерной скорости логирования, что приводит к потере сообщений syslog и невозможности записи сервисных логов. Часто проблема наблюдается при включении дополнительного логирования NSX, когда файл dfwpktlogs.log превышает допустимую скорость записи syslog. Однако причиной может быть и любая другая служба, создающая чрезмерный объём логов. Данный результат отображается при появлении соответствующих сообщений в vmkernel.log на хосте ESX.

Часто встречающиеся проблемы (Trending Issues)

KB 383273:

На хостах ESXi 8.0.2 и 8.0.3 фиксируются предупреждения “Miss counters detected” для драйверов Mellanox с ошибкой

nmlx5_QueryNicVportContext:188 command failed: IO was aborted.

Это известная ошибка в механизме проверки состояния драйвера, при которой NIC ошибочно определяется как неисправный. Исправлено в ESX 8.0 Update 3e (драйвер nmlx5 версии 4.23.6.5).

KB 318712:

Во время выполнения VCF Operations for Logs Query хост ESX сообщает о состоянии Permanent Device Loss (PDL). В Storage View хранилище отображается как недоступное, а адаптер сообщает об утере связи с устройством (Lost Communication). Все пути к устройству помечаются как «мертвые» (All Paths Down, APD). В результате невозможно подключиться к хосту через vSphere Client, и хост отображается как Disconnected в vCenter. Данный результат фиксируется при обнаружении соответствующих сообщений в vmkernel.log.

Находки, предложенные клиентами (Findings Nominated)

Главная цель команды Diagnostics — удовлетворённость клиентов. VMware стремится защитить их инфраструктуру, предоставляя результаты, основанные на опыте работы службы поддержки Broadcom, также принимаются предложения и от пользователей.

Так, например, появилась KB #385443:

На узлах vSAN происходит PSOD (Purple Screen of Death) из-за «зависших» операций ввода-вывода после сбоя диска. Команда ввода-вывода помечается как «застрявшая», а когда она завершается, соответствующие объекты уже освобождены, что вызывает сбой. Исправлено в ESX 8.0 Update 3e.

Чтобы ознакомиться со всеми диагностическими результатами в Diagnostics for VMware Cloud Foundation, откройте Findings Catalog в разделе Diagnostics Findings интерфейса VCF Operations. Для получения актуальных обновлений подпишитесь на Diagnostics for VMware Cloud Foundation Findings KB — он обновляется при каждом выпуске нового пакета или обновлении встроенных диагностических данных.

Команда поддержки VMware в Broadcom полностью привержена тому, чтобы помочь клиентам в процессе обновлений. Поскольку дата окончания общего срока поддержки VMware vSphere 7 наступила 2 октября 2025 года, многие пользователи обращаются к вендору в поисках лучших практик и пошаговых руководств по обновлению. И на этот раз речь идет не только об обновлениях с VMware vSphere 7 до VMware vSphere 8. Наблюдается активный рост подготовки клиентов к миграции с vSphere 7 на VMware Cloud Foundation (VCF) 9.0.

Планирование и выполнение обновлений может вызывать стресс, поэтому в VMware решили, что новый набор инструментов для обновления будет полезен клиентам. Чтобы сделать процесс максимально гладким, техническая команда VMware подготовила полезные ресурсы для подготовки к апгрейдам, которые помогут обеспечить миграцию инфраструктуры без серьезных проблем.

Чтобы помочь в этом процессе, каким бы он ни был, были подготовлены руководства в формате статей базы знаний (KB), которые проведут вас через весь процесс от начала до конца. Этот широкий набор статей базы знаний по обновлениям продуктов предоставляет простые, пошаговые инструкции по процессу обновления, выделяя области, требующие особого внимания, на каждом из следующих этапов:

• Подготовка к обновлению
• Последовательность и порядок выполнения апгрейда
• Необходимые действия после переезда и миграции

Ниже приведен набор статей базы знаний об обновлениях, с которым настоятельно рекомендуется ознакомиться до проведения обновления инфраструктуры vSphere и других компонентов платформы VCF.

• Обновление VMware Cloud Foundation (VCF) 4.x и 5.x
• Обновление ESXi 7.x до 8.x или установка ESXi
• Обновление vCenter Server 7.0 до 8.0
• Обновление до VMware vSAN 8
• Обновление до VMware Live Site Recovery 9.0
• Обновление до vSphere Replication 9.0
• Обновление до Aria Automation 8.18.x
• Обновление до Aria Suite Lifecycle 8.18
• Обновление до Aria Operations for Logs 8.18.x
• Обновление до Aria Operations 8.18.x
• Обновление Aria Operations for Network через графический интерфейс
• Обновление до VMware Cloud Director 10.6
• Обновление HCX
• Обновление NSX

Современная инфраструктура не прощает простоев. Любая потеря доступности данных — это не только бизнес-риск, но и вопрос репутации.
VMware vSAN, будучи ядром гиперконвергентной архитектуры VMware Cloud Foundation, всегда стремился обеспечивать высокую доступность и устойчивость хранения. Но с появлением Express Storage Architecture (ESA) подход к отказоустойчивости изменился фундаментально.

Документ vSAN Availability Technologies (часть VCF 9.0) описывает, как именно реализована устойчивость на уровне данных, сетей и устройств. Разберём, какие технологии стоят за доступностью vSAN, и почему переход к ESA меняет правила игры.

Архитектура отказоустойчивости: OSA против ESA

OSA — классика, но с ограничениями

Original Storage Architecture (OSA) — традиционный вариант vSAN, основанный на концепции дисковых групп (disk groups):

• Одно кэш-устройство (SSD)
• Несколько накопителей ёмкости (HDD/SSD)

Проблема в том, что выход из строя кеш-диска делает всю группу недоступной. Кроме того, классическая зеркальная защита (RAID-1) неэффективна по ёмкости: чтобы выдержать один отказ, приходится хранить копию 1:1.

ESA — новое поколение хранения

Express Storage Architecture (ESA) ломает эту модель:

• Нет больше disk groups — каждый накопитель независим.
• Используется кодирование erasure coding (RAID-5/RAID-6) как стандарт, без потери производительности.
• Архитектура разделена на performance leg и capacity leg — баланс скорости и надёжности.
• Встроен мониторинг NVMe-износа, зеркалирование метаданных и прогноз отказов устройств.

В результате ESA уменьшает "зону взрыва" при сбое и повышает эффективность хранения до 30–50 %, особенно при политике FTT=2.

Как vSAN обеспечивает доступность данных

Всё в vSAN строится вокруг объектов (диски ВМ, swap, конфигурации). Каждый объект состоит из компонентов, которые распределяются по узлам.
Доступность объекта определяется параметром FTT (Failures To Tolerate) — числом отказов, которые система выдержит без потери данных.

Например:

• FTT=1 (RAID-1) — один отказ хоста или диска.
• FTT=2 (RAID-6) — два отказа одновременно.
• RAID-5/6 обеспечивает ту же устойчивость, но с меньшими затратами ёмкости.

Механизм кворума

Каждый компонент имеет "голос". Объект считается доступным, если более 50 % голосов доступны. Это предотвращает split-brain-ситуации, когда две части кластера считают себя активными.

В сценариях 2-Node или stretched-cluster добавляется witness-компонент — виртуальный "свидетель", решающий, какая часть кластера останется активной.

Домены отказов и географическая устойчивость

vSAN позволяет группировать узлы в домены отказов — например, по стойкам, стойкам или площадкам. Данные и компоненты одной ВМ никогда не размещаются в пределах одного домена, что исключает потерю данных при отказе стойки или сайта.

В растянутом кластере (stretched cluster) домены соответствуют сайтам, а witness appliance располагается в третьей зоне для арбитража.

Рекомендация: проектируйте кластер не по минимуму (3–4 узла), а с запасом. Например, для FTT=2 нужно минимум 6 узлов, но VMware рекомендует 7, чтобы система могла восстановить избыточность без потери устойчивости.

Поведение при сбоях: состояния компонентов

vSAN отслеживает каждое состояние компонентов:

Компоненты в состоянии Absent ждут по умолчанию 60 минут перед восстановлением — чтобы избежать лишнего трафика из-за кратковременных сбоев.
Если восстановление невозможно, создаётся новая копия на другом узле.

Сеть как основа устойчивости

vSAN — это распределённое хранилище, и его надёжность напрямую зависит от сети.

• Транспорт — TCP/unicast с внутренним протоколом Reliable Datagram Transport (RDT).
• Поддерживается RDMA (RoCE v2) для минимизации задержек.
• Рекомендуется:
  • 2 NIC на каждый хост;
  • Подключение к разным коммутаторам;
  • Active/Standby teaming для vSAN-трафика (предсказуемые пути).

Если часть сети теряет связность, vSAN формирует partition groups и использует кворум, чтобы определить, какая группа "основная". vSAN тесно интегрирован с vSphere HA, что обеспечивает синхронное понимание состояния сети и автоматический рестарт ВМ при отказах.

Ресинхронизация и обслуживание

Resync (восстановление)

Когда хост возвращается в строй или изменяется политика, vSAN ресинхронизирует данные для восстановления FTT-уровня. В ESA ресинхронизация стала интеллектуальной и возобновляемой (resumable) — меньше нагрузка на сеть и диски.

Maintenance Mode

При вводе хоста в обслуживание доступны три режима:

1. Full Data Migration — полная миграция данных (долго, безопасно).
2. Ensure Accessibility — минимальный перенос для сохранения доступности (дефолт).
3. No Data Migration — без переноса (быстро, рискованно).

ESA использует durability components, чтобы временно сохранить данные и ускорить возврат в строй.

Предиктивное обслуживание и мониторинг

VMware внедрила целый ряд механизмов прогнозирования и диагностики:

• Degraded Device Handling (DDH) — анализ деградации накопителей по задержкам и ошибкам до фактического отказа.
• NVMe Endurance Tracking — контроль износа NVMe с предупреждениями в vCenter.
• Low-Level Metadata Resilience — зеркалирование метаданных для защиты от URE-ошибок.
• Proactive Hardware Management — интеграция с OEM-телеметрией и предупреждения через Skyline Health.

Эти механизмы в ESA работают точнее и с меньшими ложными срабатываниями по сравнению с OSA.

Доступность не равно защита данных

VMware подчёркивает разницу между понятиями:

• Availability — локальная устойчивость (хост, диск, сеть).
• Disaster Recovery — восстановление после катастрофы (вторая площадка, репликация, резервное копирование).

vSAN отвечает за первое. Для второго используются VMware SRM, vSphere Replication и внешние DR-решения. Однако комбинация vSAN ESA + stretched cluster уже позволяет реализовать site-level resilience без отдельного DR-инструмента.

Практические рекомендации

1. Используйте ESA при проектировании новых кластеров.
   Современные NVMe-узлы и сети 25 GbE позволяют реализовать отказоустойчивость без потери производительности.
2. Проектируйте с запасом по хостам.
   Один дополнительный узел обеспечит восстановление без снижения FTT-уровня.
3. Настройте отказоустойчивую сеть.
   Два интерфейса, разные коммутаторы, Route Based on Port ID — минимальные требования для надёжного vSAN-трафика.
4. Следите за здоровьем устройств.
   Активируйте DDH и NVMe Endurance Monitoring, используйте Skyline Health для предиктивного анализа.
5. Планируйте обслуживание грамотно.
   Режим Ensure Accessibility — оптимальный баланс между безопасностью и скоростью.

Заключение

VMware vSAN уже давно стал стандартом для гиперконвергентных систем, но именно с Express Storage Architecture он сделал шаг от "устойчивости" к "самоисцеляемости". ESA сочетает erasure coding, предиктивную аналитику и глубокую интеграцию с платформой vSphere, обеспечивая устойчивость, производительность и эффективность хранения. Для архитекторов и инженеров это значит одно: устойчивость теперь проектируется не как надстройка, а как неотъемлемая часть самой архитектуры хранения.

В VMware Cloud Foundation (VCF) 9.0 был представлен ряд новых и интересных функций и возможностей, которые помогают клиентам создавать гибкое, производительное и безопасное самообслуживаемое частное облако. В рамках стратегии частного облака крайне важно обеспечить способ потребления базовых инфраструктурных сервисов и быструю доставку приложений при одновременном управлении политиками и контролем.

В VCF доступно множество облачных сервисов, таких как сервисы виртуальных машин и кластеров Kubernetes, а также сервисы для управления базами данных, конвейеров непрерывной доставки, сервисной сетки, реестра образов и многое другое.

Ниже представлен обзор некоторых основных сервисов, таких как сервисы виртуальных машин и Kubernetes, а также применение к ним политик ресурсов IaaS. Политики ресурсов помогают обеспечивать соответствие конфигураций, например размеров кластеров. Настройки безопасности, такие как применение базового уровня безопасности подов или запрет на развертывание определённых ресурсов, — лишь несколько таких примеров использования политик ресурсов.

Выбор моделей потребления

С VCF администраторы организаций могут выбирать, как изолировать пользователей и ресурсы, используя такие конструкции, как организации (тенанты), проекты, пространства имён и т. д. Потребители, такие как разработчики и команды приложений, также могут выбирать способ потребления. На графике ниже показаны два основных метода: каталог самообслуживания и UI/CLI.

Единая платформа для создания и управления приложениями

VMware Cloud Foundation — это единая платформа для создания и управления приложениями и сервисами для всей организации (тенантов). ИТ-команды могут запускать и управлять разнообразными рабочими нагрузками, включая AI/ML и облачные нативные приложения. Команды могут использовать современный интерфейс (UI + код) для упрощения развертывания таких сервисов, как базы данных и виртуальные машины. Сервисы каталога предоставляют способ формировать набор приложений, которые пользователи могут запрашивать.

Администраторы могут расширять набор сервисов VCF дополнительными службами, которые могут понадобиться пользователям для их рабочих нагрузок. vSphere Supervisor создаёт управляющую точку Kubernetes на гипервизоре, что позволяет развертывать виртуальные машины и кластеры на базе Kubernetes, а также другие сервисы. Типы сервисов варьируются в зависимости от реестра образов, сервисов резервного копирования, сервисов баз данных, кластеров Kubernetes и многого другого!

Далее мы обсудим два следующих сервиса в контексте применения политик.

• vSphere Kubernetes Service: позволяет пользователям легко использовать стандартизированные, соответствующие требованиям кластеры Kubernetes, обеспечивая единообразие во всех контейнеризированных средах.
• VM Service: даёт пользователям возможность самостоятельно создавать виртуальные машины без необходимости прямого доступа к vSphere Client, упрощая создание ВМ наряду с рабочими процессами Kubernetes.

Развёртывание ВМ и кластеров VKS

Начнём с VM Service, который предоставляет современный метод потребления виртуальных машин. Используя декларативные манифесты Kubernetes YAML, пользователи могут развертывать и управлять виртуальными машинами вместе с кластерами Kubernetes. Команды разработчиков приложений, например, могут захотеть запускать виртуальные машины рядом с подами Kubernetes. Это также обеспечивает единообразный способ предоставления ресурсов для команд приложений во всём парке VCF.

Виртуальная машина разворачивается с помощью vmoperator, который представляет собой определение CRD: VM Operator. Например, для развертывания виртуальной машины может использоваться такой манифест Kubernetes:

apiVersion: vmoperator.vmware.com/v1alpha4
metadata:
kind: VirtualMachine
  name: my-vm
spec:
  className:    my-vm-class
  imageName:    vmi-0a0044d7c690bcbea
  storageClass: my-storage-class
  bootstrap:
    cloudInit:
      cloudConfig: {}

Приведённый выше манифест Kubernetes может быть создан с нуля и, например, использован в качестве шаблона, либо пользователи могут создать его с помощью интуитивно понятного интерфейса Services UI, который также развернёт для них виртуальную машину. YAML-файл для развертывания ВМ затем можно редактировать через UI или CLI.

При использовании Services UI для развертывания кластеров VKS доступны два типа конфигурации: Default Configuration, которая автоматически заполняет ряд параметров, и Custom Configuration, позволяющая выполнить более детальную настройку. В приведённом ниже примере была выбрана Default Configuration.

Потребление и развертывание через каталог

Ранее мы упоминали, что пользователи должны иметь выбор в том, как они хотят использовать инфраструктуру и развертывать приложения. До этого мы рассмотрели метод с использованием UI, где пользователь может через интуитивно понятную форму создавать виртуальные машины, кластеры VKS и вспомогательные объекты, такие как балансировщики нагрузки.

В этом разделе мы рассмотрим возможность предоставления подготовленных приложений через каталог. Элементы, находящиеся в каталоге, обычно используются для двух целей:

• Потребление базовых IaaS-компонентов и развертывание приложений и сервисов
• Запуск ad-hoc рабочих процессов и скриптов для XaaS

Далее мы сосредоточимся на первом случае. При создании элементов каталога мы можем сначала подготовить шаблоны (blueprints). VCF 9.0 предлагает простой в использовании сервис каталога. После завершения подготовки шаблона его можно опубликовать в каталог.

Теперь, когда элемент каталога для нашего приложения доступен пользователям, администраторы организации могут захотеть применить политики к развертываниям сервисов.

Тип политики для ресурсов Kubernetes

В VCF Automation 9.0 был представлен новый тип политики ресурсов: IaaS Resource Policy. Этот тип политики обеспечивает подход policy-as-code, используя Kubernetes Validation Admission Control Policy с языком CEL.

Нажав на политику ресурсов IaaS, администраторы могут настроить политики, которые будут применяться к развертываемым объектам Kubernetes, таким как виртуальные машины VM Service и кластеры Kubernetes. В примере ниже показана политика, которая ограничивает максимум одним узлом управления/рабочим узлом в кластере Kubernetes. Существует ряд готовых шаблонов, и это один из них.

Когда пользователь пытается развернуть кластер VKS с тремя управляющими узлами, при развертывании возникает ошибка, указывающая на нарушение политики.

Политика управления доступом предотвратила развертывание из-за того, что пользователь запросил больше одного управляющего узла. Это лишь один из примеров использования нового механизма policy-as-code для ресурсов Kubernetes.

Применение и настройка политик с VCF стали намного проще. Администраторы могут предоставлять конечным пользователям гибкость и скорость в потреблении инфраструктуры без ущерба для безопасности, соответствия требованиям и организационных политик.

Введение

В современных ИТ-системах шифрование данных стало обязательным элементом защиты информации. Цель шифрования — гарантировать, что данные могут прочитать только системы, обладающие нужными криптографическими ключами. Любой, не имеющий ключей доступа, увидит лишь бессмысленный набор символов, поскольку информация надёжно зашифрована устойчивым алгоритмом AES-256. VMware vSAN поддерживает два уровня шифрования для повышения безопасности кластерного хранения данных: шифрование данных на носителях (Data-at-Rest Encryption) и шифрование данных при передаче (Data-in-Transit Encryption). Эти механизмы позволяют защитить данные как в состоянии покоя (на дисках), так и в движении (между узлами кластера). В результате vSAN помогает организациям соответствовать требованиям регуляторов и предотвращать несанкционированный доступ к данным, например, при краже носителей или перехвате сетевого трафика.

Сегодня мы расскажем о шифровании данных в платформе VMware vSAN, если вы хотите получить больше подробностей, то обратитесь к документу "vSAN Encryption Services: Understanding Encryption Offerings with vSAN using VMware Cloud Foundation 9.0".

Архитектура и компоненты vSAN Encryption Services

Компоненты решения

Архитектура шифрования vSAN включает несколько ключевых элементов: внешний или встроенный сервер управления ключами (KMS), сервер VMware vCenter, гипервизоры ESXi в составе vSAN-кластера и собственно криптографические модули в ядре гипервизора. Внешний KMS-сервер (совместимый с протоколом KMIP), либо встроенный поставщик ключей vSphere NKP, обеспечивает генерацию и хранение мастер-ключей шифрования. vCenter Server отвечает за интеграцию с KMS: именно vCenter устанавливает доверенные отношения (обмен сертификатами) с сервером ключей и координирует выдачу ключей хостам ESXi. Каждый узел ESXi, входящий в шифрованный кластер vSAN, содержит встроенный криптомодуль VMkernel (сертифицированный по требованиям FIPS), который выполняет операции шифрования и дешифрования данных на стороне гипервизора.

Распределение ключей

При включении шифрования vSAN на кластере vCenter запрашивает у KMS два ключа для данного кластера: ключ шифрования ключей (Key Encryption Key, KEK) и ключ хоста (Host Key). KEK играет роль мастер-ключа: с его помощью будут шифроваться все остальные ключи (например, ключи данных). Host Key предназначен для защиты дампов памяти (core dumps) и других служебных данных хоста. После получения этих ключей vCenter передаёт информацию о KMS и идентификаторы ключей (ID) всем хостам кластера. Каждый узел ESXi устанавливает прямое соединение с KMS (по протоколу KMIP) и получает актуальные копии KEK и Host Key, помещая их в защищённый кэш памяти.

Важно: сами ключи не сохраняются на диске хоста, они хранятся только в оперативной памяти или, при наличии, в аппаратном модуле TPM на узле. Это означает, что при перезагрузке хоста ключи стираются из памяти и в общем случае должны быть вновь запрошены у KMS, прежде чем хост сможет монтировать зашифрованное хранилище.

Ключи данных (DEK)

Помимо вышеупомянутых кластерных ключей, каждый диск или объект данных получает свой собственный ключ шифрования данных (Data Encryption Key, DEK). В оригинальной архитектуре хранения vSAN (OSA) гипервизор генерирует уникальный DEK (алгоритм XTS-AES-256) для каждого физического диска в дисковой группе. Эти ключи оборачиваются (wrap) с помощью кластерного KEK и сохраняются в метаданных, что позволяет безопасно хранить ключи на дисках: получить «сырой» DEK можно только расшифровав его при помощи KEK. В более новой архитектуре vSAN ESA подход несколько отличается: используется единый ключ шифрования кластера, но при этом для различных объектов данных применяются уникальные производные ключи. Благодаря этому данные каждой виртуальной машины шифруются своим ключом, даже если в основе лежит общий кластерный ключ. В обоих случаях vSAN обеспечивает надёжную защиту: компрометация одного ключа не даст злоумышленнику доступа ко всему массиву данных.

Роль гипервизора и производительность

Шифрование в vSAN реализовано на уровне ядра ESXi, то есть прозрачно для виртуальных машин. Гипервизор использует сертифицированный криптографический модуль VMkernel, прошедший все необходимые проверки по стандарту FIPS 140-2 (а в новых версиях — и FIPS 140-3). Все операции шифрования выполняются с использованием аппаратного ускорения AES-NI, что минимизирует влияние на производительность системы. Опыт показывает, что нагрузка на CPU и задержки ввода-вывода при включении шифрования vSAN обычно незначительны и хорошо масштабируются с ростом числа ядер и современных процессоров. В свежей архитектуре ESA эффективность ещё выше: благодаря более оптимальному расположению слоя шифрования в стеке vSAN, для той же нагрузки требуется меньше CPU-циклов и операций, чем в классической архитектуре OSA.

Управление доступом

Стоит упомянуть, что управление шифрованием в vSAN встроено в систему ролей и привилегий vCenter. Только пользователи с особыми правами (Cryptographic administrator) могут настраивать KMS и включать/отключать шифрование на кластере. Это добавляет дополнительный уровень безопасности: случайный администратор без соответствующих привилегий даже не увидит опцию включения шифрования в интерфейсе. Разграничение доступа гарантирует, что ключи шифрования и связанные операции контролируются ограниченным кругом доверенных администраторов.

Поддерживаемые типы шифрования

Шифрование данных на носителях (vSAN Data-at-Rest Encryption)

Этот тип шифрования обеспечивает защиту всех данных, хранящихся в vSAN-датасторе. Включение функции означает, что вся информация, записываемая на диски кластера, автоматически шифруется на последнем этапе ввода-вывода перед сохранением на устройство. При чтении данные расшифровываются гипервизором прозрачно для виртуальных машин – приложения и ОС внутри ВМ не осведомлены о том, что данные шифруются. Главное назначение Data-at-Rest Encryption – обезопасить данные на случай, если накопитель будет изъят из системы (например, при краже или некорректной утилизации дисков).

Без соответствующих ключей злоумышленник не сможет прочитать информацию с отключенного от кластера диска. Шифрование «на покое» не требует специальных самошифрующихся дисков – vSAN осуществляет его программно, используя собственные криптомодули, и совместимо как с гибридными, так и полностью флэш-конфигурациями хранилища.

Принцип работы: в оригинальной реализации OSA шифрование данных происходит после всех операций дедупликации и сжатия, то есть уже на «выходе» перед записью на носитель. Такой подход позволяет сохранить эффективность экономии места: данные сначала сжимаются и устраняются дубликаты, и лишь затем шифруются, благодаря чему коэффициенты дедупликации/сжатия не страдают. В архитектуре ESA шифрование интегрировано выше по стеку – на уровне кэша – но всё равно после выполнения компрессии данных.

То есть в ESA шифрование также не препятствует сжатию. Однако особенностью ESA является то, что все данные, покидающие узел, уже зашифрованы высокоуровневым ключом кластера (что частично перекрывает и трафик между узлами – см. ниже). Тем не менее для обеспечения максимальной криптостойкости vSAN ESA по-прежнему поддерживает отдельный механизм Data-in-Transit Encryption для уникального шифрования каждого сетевого пакета.

Включение и поддержка: шифрование данных на носителях включается на уровне всего кластера vSAN – достаточно установить флажок «Data-at-Rest Encryption» в настройках служб vSAN для выбранного кластера. Данная возможность доступна только при наличии лицензии vSAN Enterprise или выше.

В традиционной архитектуре OSA шифрование можно включать как при создании нового кластера, так и на уже работающем кластере. В последнем случае vSAN выполнит поочерёдное перевоспроизведение данных с каждого диска (evacuation) и форматирование дисковых групп в зашифрованном виде, что потребует определённых затрат ресурсов и времени. В архитектуре ESA, напротив, решение о шифровании принимается только на этапе создания кластера и не может быть изменено позднее без полной перестройки хранилища. Это связано с тем, что в ESA шифрование глубоко интегрировано в работу кластера, обеспечивая максимальную производительность, но и требуя фиксации режима на старте. В обоих случаях, после включения, сервис шифрования прозрачно работает со всеми остальными функциями vSAN (в том числе со снапшотами, клонированием, vMotion и т.д.) и практически не влияет на операционную деятельность кластера.

Шифрование данных при передаче (vSAN Data-in-Transit Encryption)

Второй компонент системы безопасности vSAN – это шифрование сетевого трафика между узлами хранения. Функция Data-in-Transit Encryption гарантирует, что все данные, пересылаемые по сети между хостами vSAN, будут зашифрованы средствами гипервизора.

Это особенно важно, если сеть хранения не полностью изолирована или если требуется соответствовать строгим стандартам по защите данных в транзите. Механизм шифрования трафика не требует KMS: при включении этой опции хосты vSAN самостоятельно генерируют и обмениваются симметричными ключами для установления защищённых каналов. Процесс полностью автоматизирован и не требует участия администратора – достаточно активировать настройку в параметрах кластера.

Data-in-Transit Encryption впервые появилась в vSAN 7 Update 1 и доступна для кластеров как с OSA, так и с ESA. В случае OSA администратор может независимо включить шифрование трафика (оно не зависит от шифрования на дисках, но для полноты защиты желательно задействовать оба механизма). В случае ESA отдельного переключателя может не потребоваться: при создании кластера с шифрованием данные «на лету» фактически уже будут выходить из узлов зашифрованными единым высокоуровневым ключом. Однако, чтобы каждый сетевой пакет имел уникальный криптографический отпечаток, ESA по-прежнему предусматривает опцию Data-in-Transit (она остаётся активной в интерфейсе и при включении обеспечит дополнительную уникализацию шифрования каждого пакета). Следует учесть, что на момент выпуска vSAN 9.0 в составе VCF 9.0 шифрование трафика поддерживается только для обычных (HCI) кластеров vSAN и недоступно для т. н. disaggregated (выделенных storage-only) кластеров.

С технической точки зрения, Data-in-Transit Encryption использует те же проверенные криптомодули, сертифицированные по FIPS 140-2/3, что и шифрование данных на дисках. При активации этой функции vSAN автоматически выполняет взаимную аутентификацию хостов и устанавливает между ними защищённые сессии с помощью динамически создаваемых ключей. Когда новый узел присоединяется к шифрованному кластеру, для него генерируются необходимые ключи и он аутентифицируется существующими участниками; при исключении узла его ключи отзываются, и трафик больше не шифруется для него. Всё это происходит «под капотом», не требуя ручной настройки. В результате даже при потенциальном перехвате пакетов vSAN-трафика на уровне сети, извлечь из них полезные данные не представляется возможным.

Интеграция с KMS

Требование наличия KMS

Для использования шифрования данных на vSAN необходим сервер управления ключами (Key Management Server, KMS), совместимый со стандартом KMIP 1.1+. Исключение составляет вариант применения встроенного поставщика ключей vSphere (Native Key Provider, NKP), который появился начиная с vSphere 7.0 U2. Внешний KMS может быть программным или аппаратным (множество сторонних решений сертифицировано для работы с vSAN), но в любом случае требуется лицензия не ниже vSAN Enterprise.

Перед включением шифрования администратор должен зарегистрировать KMS в настройках vCenter: добавить информацию о сервере и установить доверие между vCenter и KMS. Обычно настройка доверия реализуется через обмен сертификатами: vCenter либо получает от KMS корневой сертификат (Root CA) для проверки подлинности, либо отправляет на KMS сгенерированный им запрос на сертификат (CSR) для подписи. В результате KMS и vCenter обмениваются удостоверяющими сертификатами и устанавливают защищённый канал. После этого vCenter может выступать клиентом KMS и запрашивать ключи.

В конфигурации с Native Key Provider процесс ещё проще: NKP разворачивается непосредственно в vCenter, генерируя мастер-ключ локально, поэтому внешний сервер не нужен. Однако даже в этом случае рекомендуется экспортировать (зарезервировать) копию ключа NKP во внешнее безопасное место, чтобы избежать потери ключей в случае сбоя vCenter.

Запрос и кэширование ключей

Как только доверие (trust) между vCenter и KMS установлено, можно активировать шифрование vSAN на уровне кластера. При этом vCenter от имени кластера делает запрос в KMS на выдачу необходимых ключей (KEK и Host Key) и распределяет их идентификаторы хостам, как описано выше. Каждый ESXi узел соединяется с KMS напрямую для получения своих ключей. На период нормальной работы vSAN-хосты обмениваются ключами с KMS напрямую, без участия vCenter.

Это означает, что после первоначальной настройки для ежедневной работы кластера шифрования доступность vCenter не критична – даже если vCenter временно выключен, хосты будут продолжать шифровать/расшифровывать данные, используя ранее полученные ключи. Однако vCenter нужен для проведения операций управления ключами (например, генерации новых ключей, смены KMS и пр.). Полученные ключи хранятся на хостах в памяти, а при наличии TPM-модуля – ещё и в его защищённом хранилище, что позволяет пережить перезагрузку хоста без немедленного запроса к KMS.

VMware настоятельно рекомендует оснащать все узлы vSAN доверенными платформенными модулями TPM 2.0, чтобы обеспечить устойчивость к отказу KMS: если KMS временно недоступен, хосты с TPM смогут перезапускаться и монтировать зашифрованное хранилище, используя кешированные в TPM ключи.

Лучшие практики KMS

В контексте vSAN есть важное правило: не размещать сам KMS на том же зашифрованном vSAN-хранилище, которое он обслуживает. Иначе возникает круговая зависимость: при отключении кластера или перезагрузке узлов KMS сам окажется недоступен (ведь он работал как ВМ на этом хранилище), и хосты не смогут получить ключи для расшифровки датасторов.

Лучше всего развернуть кластер KMS вне шифруемого кластера (например, на отдельной инфраструктуре или как облачный сервис) либо воспользоваться внешним NKP от другого vCenter. Также желательно настроить кластер из нескольких узлов KMS (для отказоустойчивости) либо, в случае NKP, надёжно сохранить резервную копию ключа (через функцию экспорта в UI vCenter).

При интеграции с KMS крайне важна корректная сетевая настройка: все хосты vSAN-кластера должны иметь прямой доступ к серверу KMS (обычно по протоколу TLS на порт 5696). В связке с KMS задействуйте DNS-имя для обращения (вместо IP) – это упростит перенастройку в случае смены адресов KMS и снизит риск проблем с подключением.

vSphere Native Key Provider

Этот встроенный механизм управления ключами в vCenter заслуживает отдельного упоминания. NKP позволяет обойтись без развертывания отдельного KMS-сервера, что особенно привлекательно для небольших компаний или филиалов. VMware поддерживает использование NKP для шифрования vSAN начиная с версии 7.0 U2. По сути, NKP хранит мастер-ключ в базе данных vCenter (в зашифрованном виде) и обеспечивает необходимые функции выдачи ключей гипервизорам. При включении шифрования vSAN с NKP процесс выдачи ключей аналогичен: vCenter генерирует KEK и распределяет его на хосты. Разница в том, что здесь нет внешнего сервера – все операции выполняются средствами самого vCenter.

Несмотря на удобство, у NKP есть ограничения (например, отсутствие поддержки внешних интерфейсов KMIP для сторонних приложений), поэтому для крупных сред на долгосрочной основе часто выбирают полноценный внешний KMS. Тем не менее, NKP – это простой способ быстро задействовать шифрование без дополнительных затрат, и он идеально подходит для многих случаев использования.

Процесс шифрования и дешифрования

Запись данных (шифрование)

После того как кластер vSAN сконфигурирован для шифрования и получены необходимые ключи, каждая операция записи данных проходит через этап шифрования в гипервизоре. Рассмотрим упрощённо этот процесс на примере OSA (Original Storage Architecture):

• Получение блока данных. Виртуальная машина записывает данные на диск vSAN, которые через виртуальный контроллер поступают на слой vSAN внутри ESXi. Там данные сначала обрабатываются сервисами оптимизации – например, вычисляются хеши для дедупликации и выполняется сжатие (если эти функции включены на кластере).
• Шифрование блока. Когда очередь дошла до фактической записи блока на устройство, гипервизор обращается к ключу данных (DEK), связанному с целевым диском, и шифрует блок по алгоритму AES-256 (режим XTS) с помощью этого DEK. Как упоминалось, в OSA у каждого диска свой DEK, поэтому даже два диска одного узла шифруют данные разными ключами. Шифрование происходит на уровне VMkernel, используя AES-NI, и добавляет минимальную задержку.
• Запись на устройство. Зашифрованный блок записывается в кеш или напрямую на SSD в составе дисковой группы. На носитель попадают только зашифрованные данные; никакой незашифрованной копии информации на диске не сохраняется. Метаданные vSAN также могут быть зашифрованы или содержать ссылки на ключ (например, KEK_ID), но без владения самим ключом извлечь полезную информацию из зашифрованного блока невозможно.

В архитектуре ESA процесс схож, с тем отличием, что шифрование происходит сразу после сжатия, ещё на высокоуровневом слое ввода-вывода. Это означает, что данные выходят из узла уже шифрованными кластерным ключом. При наличии Data-in-Transit Encryption vSAN накладывает дополнительное пакетное шифрование: каждый сетевой пакет между хостами шифруется с использованием симметрических ключей сеанса, которые регулярно обновляются. Таким образом, данные остаются зашифрованы как при хранении, так и при передаче по сети, что создаёт многослойную защиту (end-to-end encryption).

Чтение данных (дешифрование)

Обратный процесс столь же прозрачен. Когда виртуальная машина запрашивает данные из vSAN, гипервизор на каждом затронутом хосте находит нужные зашифрованные блоки на дисках и считывает их. Прежде чем передать данные наверх VM, гипервизор с помощью соответствующего DEK выполняет расшифровку каждого блока в памяти. Расшифрованная информация проходит через механизмы пост-обработки (восстановление сжатых данных, сборка из дедуплицированных сегментов) и отправляется виртуальной машине. Для ВМ этот процесс невидим – она получает привычный для себя блок данных, не зная, что на физическом носителе он хранится в зашифрованном виде. Если задействовано шифрование трафика, то данные могут передаваться между узлами в зашифрованном виде и расшифровываются только на том хосте, который читает их для виртуальной машины-потребителя.

Устойчивость к сбоям

При нормальной работе все операции шифрования/дешифрования происходят мгновенно для пользователя. Но стоит рассмотреть ситуацию с потенциальным сбоем KMS или перезагрузкой узла. Как отмечалось ранее, хосты кэшируют полученные ключи (KEK, Host Key и необходимые DEK) в памяти или TPM, поэтому кратковременное отключение KMS не влияет на работающий кластер.

Виртуальные машины продолжат и читать, и записывать данные, пользуясь уже загруженными ключами. Проблемы могут возникнуть, если перезагрузить хост при недоступном KMS: после перезапуска узел не сможет получить свои ключи для монтирования дисковых групп, и его локальные компоненты хранилища останутся офлайн до восстановления связи с KMS. Именно поэтому, как уже упоминалось, рекомендуется иметь резервный KMS (или NKP) и TPM-модули на узлах, чтобы повысить отказоустойчивость системы шифрования.

Управление ключами и ротация

Замена ключей (Rekey)

Безопасность криптосистемы во многом зависит от регулярной смены ключей. VMware vSAN предоставляет администраторам возможность проводить плановую ротацию ключей шифрования без простоя и с минимальным влиянием на работу кластера. Поддерживаются два режима: «мелкая» ротация (Shallow Rekey) и «глубокая» ротация (Deep Rekey). При shallow rekey генерируется новый мастер-ключ KEK, после чего все ключи данных (DEK) перешифровываются этим новым KEK (старый KEK уничтожается). Важно, что сами DEK при этом не меняются, поэтому операция выполняется относительно быстро: vSAN просто обновляет ключи в памяти хостов и в метаданных, не перестраивая все данные на дисках. Shallow rekey обычно используют для регулярной смены ключей в целях комплаенса (например, раз в квартал или при смене ответственного администратора).

Deep rekey, напротив, предполагает полную замену всех ключей: генерируются новые DEK для каждого объекта/диска, и все данные кластера постепенно перераспределяются и шифруются уже под новыми ключами. Такая операция более ресурсоёмка, фактически аналогична повторному шифрованию всего объёма данных, и может занять продолжительное время на крупных массивах. Глубокую ротацию имеет смысл выполнять редко – например, при подозрении на компрометацию старых ключей или после аварийного восстановления системы, когда есть риск утечки ключевой информации. Оба типа рекея можно инициировать через интерфейс vCenter (в настройках кластера vSAN есть опция «Generate new encryption keys») или с помощью PowerCLI-скриптов. При этом для shallow rekey виртуальные машины могут продолжать работать без простоев, а deep rekey обычно тоже выполняется онлайн, хотя и создаёт повышенную нагрузку на подсистему хранения.

Смена KMS и экспорт ключей

Если возникает необходимость поменять используемый KMS (например, миграция на другого вендора или переход от внешнего KMS к встроенному NKP), vSAN упрощает эту процедуру. Администратор добавляет новый KMS в vCenter и обозначает его активным для данного кластера. vSAN автоматически выполнит shallow rekey: запросит новый KEK у уже доверенного нового KMS и переведёт кластер на использование этого ключа, перешифровав им все старые DEK. Благодаря этому переключение ключевого сервиса происходит прозрачно, без остановки работы хранилища. Тем не менее, после замены KMS настоятельно рекомендуется удостовериться, что старый KMS более недоступен хостам (во избежание путаницы) и сделать резервную копию конфигурации нового KMS/NKP.

При использовании vSphere Native Key Provider важно регулярно экспортировать зашифрованную копию ключа NKP (через интерфейс vCenter) и хранить её в безопасном месте. Это позволит восстановить доступ к зашифрованному vSAN, если vCenter выйдет из строя и потребуется его переустановка. В случае же аппаратного KMS, как правило, достаточно держать под рукой актуальные резервные копии самого сервера KMS (или использовать кластер KMS из нескольких узлов для отказоустойчивости).

Безопасное удаление данных

Одним из побочных преимуществ внедрения шифрования является упрощение процедуры безопасной утилизации носителей. vSAN предлагает опцию Secure Disk Wipe для случаев, когда необходимо вывести диск из эксплуатации или изъять узел из кластера. При включенной функции шифрования проще всего выполнить «очистку» диска путем сброса ключей: как только DEK данного носителя уничтожен (либо кластерный KEK перегенерирован), все данные на диске навсегда остаются в зашифрованном виде, то есть фактически считаются стёртыми (так называемая криптографическая санация).

Кроме того, начиная с vSAN 8.0, доступна встроенная функция стирания данных в соответствии со стандартами NIST (например, перезапись нулями или генерация случайных шаблонов). Администратор может запустить безопасное стирание при выведении диска из кластера – vSAN приведёт накопитель в состояние, удовлетворяющее требованиям безопасной утилизации, удалив все остаточные данные. Комбинация шифрования и корректного удаления обеспечивает максимальную степень защиты: даже физически завладев снятым накопителем, злоумышленник не сможет извлечь конфиденциальные данные.

Поддержка FIPS и совместимость

Соответствие стандартам (FIPS)

VMware vSAN Encryption Services были разработаны с учётом строгих требований отраслевых стандартов безопасности. Криптографический модуль VMkernel, на котором основано шифрование vSAN, прошёл валидацию FIPS 140-2 (Cryptographic Module Validation Program) ещё в 2017 году. Это означает, что реализация шифрования в гипервизоре проверена независимыми экспертами и отвечает критериям, предъявляемым правительственными организациями США и Канады.

Более того, в 2024 году VMware успешно завершила сертификацию модуля по новому стандарту FIPS 140-3, обеспечив преемственность соответствия более современным требованиям. Для заказчиков из сфер, где необходима сертификация (государственный сектор, финансы, медицина и т.д.), это даёт уверенность, что vSAN может использоваться для хранения чувствительных данных. Отдельно отметим, что vSAN включена в руководства по безопасности DISA STIG для Министерства обороны США, а также поддерживает механизмы двухфакторной аутентификации администраторов (RSA SecurID, CAC) при работе с vCenter — всё это подчёркивает серьёзное внимание VMware к безопасности решения.

Совместимость с функционалом vSAN

Шифрование в vSAN спроектировано так, чтобы быть максимально прозрачным для остальных возможностей хранения. Дедупликация и сжатие полностью совместимы с Data-at-Rest Encryption: благодаря порядку выполнения (сначала дедупликация/сжатие, потом шифрование) эффективность экономии места практически не снижается. Исключение составляет экспериментальная функция глобальной дедупликации в новой архитектуре ESA — на момент запуска vSAN 9.0 одновременное включение глобальной дедупликации и шифрования не поддерживается (ожидается снятие этого ограничения в будущих обновлениях).

Снапшоты и клоны виртуальных машин на зашифрованном vSAN работают штатно: все мгновенные копии хранятся в том же шифрованном виде, и при чтении/записи гипервизор так же прозрачно шифрует их содержимое. vMotion и другие механизмы миграции ВМ также поддерживаются – сама ВМ при миграции может передаваться с шифрованием (функция Encrypted vMotion, независимая от vSAN) или без него, но это не влияет на состояние ее дисков, которые на принимающей стороне всё равно будут записаны на vSAN уже в зашифрованном виде.

Резервное копирование и репликация

vSAN Encryption не накладывает ограничений на работу средств резервного копирования, использующих стандартные API vSphere (такие как VMware VADP) или репликации на уровне ВМ. Данные читаются гипервизором в расшифрованном виде выше уровня хранения, поэтому бэкап-приложения получают их так же, как и с обычного хранилища. При восстановлении или репликации на целевой кластер vSAN, естественно, данные будут записаны с повторным шифрованием под ключи того кластера. Таким образом, процессы защиты и восстановления данных (VDP, SRM, vSphere Replication и пр.) полностью совместимы с зашифрованными датасторами vSAN.

Ограничения и особенности

Поскольку vSAN реализует программное шифрование, аппаратные самошифрующиеся диски (SED) не требуются и официально не поддерживаются в роли средства шифрования на уровне vSAN. Если в серверы установлены SED-накопители, они могут использоваться, но без включения режимов аппаратного шифрования – vSAN в любом случае выполнит шифрование средствами гипервизора. Ещё один момент: при включении vSAN Encryption отключается возможность рентген-просмотра (в веб-клиенте vSAN) содержимого дисков, так как данные на них хранятся в зашифрованном виде. Однако на функциональность управления размещением объектов (Storage Policy) это не влияет. Наконец, стоит учитывать, что шифрование данных несколько повышает требования к процессорным ресурсам на хостах. Практика показывает, что современные CPU справляются с этим отлично, но при проектировании больших нагрузок (вроде VDI или баз данных на all-flash) закладывать небольшой запас по CPU будет не лишним.

Заключение

VMware vSAN Encryption Services предоставляют мощные средства защиты данных для гиперконвергентной инфраструктуры. Реализовав сквозное шифрование (от диска до сети) на уровне хранения, vSAN позволяет организациям выполнить требования по безопасности без сложных доработок приложений. Среди ключевых преимуществ решения можно отметить:

• Всесторонняя защита данных. Даже если злоумышленник получит физический доступ к носителям или перехватит трафик, конфиденциальная информация останется недоступной благодаря сильному шифрованию (AES-256) и раздельным ключам для разных объектов. Это особенно важно для соблюдения стандартов GDPR, PCI-DSS, HIPAA и других.
• Прозрачность и совместимость. Шифрование vSAN работает под управлением гипервизора и не требует изменений в виртуальных машинах. Все основные функции vSphere (кластеризация, миграция, бэкап) полностью поддерживаются. Решение не привязано к специфическому оборудованию, а опирается на открытые стандарты (KMIP, TLS), что облегчает интеграцию.
• Удобство централизованного управления. Администратор может включить шифрование для всего кластера несколькими кликами – без необходимости настраивать каждую ВМ по отдельности (в отличие от VMcrypt). vCenter предоставляет единый интерфейс для управления ключами, а встроенный NKP ещё больше упрощает старт. При этом разграничение прав доступа гарантирует, что только уполномоченные лица смогут внести изменения в политику шифрования.
• Минимальное влияние на производительность. Благодаря оптимизациям (использование AES-NI, эффективные алгоритмы) накладные расходы на шифрование невелики. Особенно в архитектуре ESA шифрование реализовано с учётом высокопроизводительных сценариев и практически не сказывается на IOPS и задержках. Отсутствуют и накладные расходы по ёмкости: включение шифрования не уменьшает полезный объём хранилища и не создаёт дублирования данных.
• Гибкость в выборе подхода. vSAN поддерживает как внешние KMS от разных поставщиков (для предприятий с уже выстроенными процессами управления ключами), так и встроенный vSphere Native Key Provider (для простоты и экономии). Администраторы могут ротировать ключи по своему графику, комбинировать или отключать сервисы при необходимости (например, включить только шифрование трафика для удалённого филиала с общим хранилищем).

При внедрении шифрования в vSAN следует учесть несколько моментов: обеспечить высокую доступность сервера KMS (или надёжно сохранить ключ NKP), активировать TPM на хостах для хранения ключей, а также не сочетать шифрование vSAN с шифрованием на уровне ВМ (VM Encryption) без крайней необходимости. Двойное шифрование не повышает безопасность, зато усложняет управление и снижает эффективность дедупликации и сжатия.

В целом же шифрование vSAN значительно повышает уровень безопасности инфраструктуры с минимальными усилиями. Оно даёт организациям уверенность, что данные всегда под надёжной защитой – будь то на дисках или в пути между узлами, сегодня и в будущем, благодаря следованию современным стандартам криптографии FIPS.

Компания VMware недавно объявила о первом результате теста VMmark 4 с использованием последнего релиза платформы виртуализации VMware Cloud Foundation (VCF) 9.0. Метрики, показанные системой Lenovo, также стали первым результатом тестирования новейшей 4-сокетной системы на базе процессора Intel Xeon серии 6700 с технологией Performance-cores, который обеспечивает большее количество ядер и более высокую пропускную способность памяти. Итоговый результат доступен на странице VMmark 4 Results.

В следующей таблице приведено сравнение нового результата Lenovo с системой предыдущего поколения ThinkSystem под управлением vSphere 8.0 Update 3:

График показывает рост общего количества ядер на 43% между этими двумя результатами:

С точки зрения очков производительности, показатель VMmark 4 вырос на 49%:

Ключевые моменты:

• Сочетание VCF 9.0 и нового серверного оборудования позволило запустить на 50% больше виртуальных машин / рабочих нагрузок (132) по сравнению с результатом предыдущего поколения (88 ВМ).
• Процессоры Intel Xeon 6788P в Lenovo ThinkSystem SR860 V4 имеют на 43% больше ядер, чем процессоры предыдущего поколения Intel Xeon Platinum 8490H в ThinkSystem SR860 V3
• Показатель VMmark на 49% выше, чем результат VMmark 4 для предыдущего поколения.

VMmark — это бесплатный инструмент тестирования, который используется партнёрами и клиентами для оценки производительности, масштабируемости и энергопотребления платформ виртуализации. Посетите страницу продукта VMmark и сообщество VMmark Community, чтобы узнать больше. Также вы можете попробовать VMmark 4 прямо сейчас через VMware Hands-on Labs Catalog, выполнив поиск по запросу «VMmark».

В частных облаках часто встречается несколько экземпляров vCenter Server. Это особенно характерно для сред VMware Cloud Foundation (VCF), поскольку подход к масштабированию емкостей заключается в развертывании дополнительных доменов рабочих нагрузок, включающих набор ресурсов vCenter Server, VMware ESX и VMware NSX. Администраторам облака, которым необходимо управлять рабочими нагрузками vSphere, гораздо удобнее, если они могут получать доступ к нескольким средам через единый экземпляр vSphere Client, и в прошлом для этого существовало несколько архитектурных решений.

До недавнего времени стандартным способом объединения нескольких сред vSphere был Enhanced Linked Mode (ELM), но VCF 9 представляет новый метод.

Режим Enhanced Linked Mode (ELM) всё ещё поддерживается в vSphere 9.0, но будет полностью упразднен в будущих релизах vSphere.

Новая возможность: группы vCenter

VCF 9 приносит значительные изменения в управление частным облаком, и одним из ключевых улучшений является полностью новая архитектура Single Sign-On (SSO) для бесшовного доступа к VCF Operations, vSphere Client, NSX Manager и другим компонентам. Теперь интеграция со стандартным провайдером идентификации стала проще, чем когда-либо, что позволяет предоставлять доступ отдельным администраторам VCF и, наконец, отказаться от совместного использования пароля пользователя «admin». Эта новая возможность SSO не поддерживает Enhanced Linked Mode, но, что ещё важнее, в ней и нет необходимости для обеспечения доступа к нескольким средам в одном vSphere Client.

Вместо этого в VCF Operations появилась новая упрощённая функция, позволяющая администраторам создавать группы серверов vCenter, которые автоматически связываются друг с другом. В сочетании с VCF SSO это обеспечивает плавный и бесшовный опыт управления vSphere.

Связывание vCenter Server

Чтобы связать ваши vCenter Server, в VCF Operations 9 перейдите в Infrastructure Operations > Configurations и выберите плитку vCenter Linking.

Оттуда нажмите Create Group и используйте простой мастер, чтобы выбрать серверы vCenter, которые вы хотите связать вместе.

Вход с использованием VCF SSO

После установления связи необходимо войти с помощью VCF SSO, чтобы видеть несколько сред в едином интерфейсе vSphere Client. Имейте в виду: если войти с использованием локальной учётной записи, например administrator@vsphere.local, то будет отображаться только инвентарь конкретной системы.

После входа в систему в левом навигационном дереве отобразится привычный вид с несколькими серверами vCenter.

Управление средой vSphere

Когда несколько сред vSphere связаны между собой с помощью vCenter Linking, вы можете заметить, что для выполнения некоторых операций требуется выбрать конкретный сервер vCenter — имейте это в виду, чтобы избежать неожиданных сюрпризов!

Итоги

Экземпляры VMware Cloud Foundation обычно включают несколько сред vSphere. Теперь вы можете использовать новый vCenter Linking с vCenter Groups, чтобы упростить управление всей инфраструктурой — бесшовно и без использования общих паролей администратора.

Одной из новых возможностей Fleet Management, представленных в VMware Cloud Foundation (VCF) 9.0, является полностью обновлённый опыт единого входа (SSO), обеспечивающий доступ администраторов ко всем основным интерфейсам управления, таким как: VCF Operations, vSphere Client, NSX Manager и другие. Новый компонент VCF Identity Broker (VIDB) поддерживает множество современных провайдеров идентификации, а также традиционные службы каталогов. В этой статье вы узнаете, как включить и настроить SSO в среде VCF 9.

Режимы развертывания – встроенный или внешний (appliance)

Первым шагом при включении VCF SSO является выбор режима развертывания брокера идентификации. Существует два варианта: встроенный или appliance.

• Встроенный вариант интегрирован с vCenter Server в домене управления и идеально подходит для небольших сред VCF, которым не требуется масштабирование до целого пула экземпляров VCF.
• Для большей масштабируемости можно выбрать вариант appliance, который работает на небольшом кластере из трёх узлов VIDB для обеспечения отказоустойчивости. Внешний вариант может предоставлять службы идентификации для всего пула экземпляров VCF и рекомендуется для инфраструктур до пяти экземпляров VCF.

Поддержка провайдеров идентификации

После выбора режима развертывания необходимо выбрать провайдера идентификации. В VCF 9 добавлена поддержка Ping Identity и универсальных провайдеров SAML 2.0 в дополнение к Okta, Entra ID, Active Directory, OpenLDAP и другим. В зависимости от выбранного провайдера будут доступны различные варианты определения групп, которым предоставляется доступ для входа в компоненты VCF. Для уточнения конкретных требований следует обратиться к документации продукта.

Ещё одним улучшением стали методы предоставления пользователей и групп: теперь, помимо SCIM с современными провайдерами идентификации, можно использовать JIT или AD/LDAP.

Конфигурация компонентов

После настройки провайдера идентификации остаётся всего один шаг, чтобы включить VCF SSO для каждого компонента в развертывании. Настройка основных инфраструктурных компонентов — vCenter Server и NSX Manager — сводится к простому выбору опции, при этом несколько сервисов можно активировать одновременно, и процесс занимает всего несколько минут.

Для компонентов управления процесс почти такой же простой, но каждый из них расположен в отдельном узле в дереве навигации, поэтому достаточно перейти туда и следовать инструкциям в интерфейсе, чтобы завершить настройку SSO.

Назначение ролей

После завершения настройки VCF SSO остаётся административная задача — назначить необходимые роли для каждого компонента. Эта одноразовая операция должна выполняться с использованием локальных учётных записей администратора (например, “admin” или “administrator@vsphere.local” в случае с vCenter Server). Необходимо предоставить доступ пользователям и группам, созданным через настроенного провайдера идентификации, и назначить им соответствующие права для управления компонентами.

Процесс может отличаться в зависимости от компонента. Например, вы можете назначить группе роль Enterprise Admin, чтобы она могла управлять NSX.

Чтобы увидеть весь процесс включения доступа в полном развертывании VCF 9, посмотрите демо ниже.

Пользовательский интерфейс SDDC Manager

Особое примечание о SDDC Manager в VCF 9: этот пользовательский интерфейс считается устаревшим, но остаётся доступным, а само backend-приложение по-прежнему необходимо для выполнения некоторых задач управления инфраструктурой. В связи с этим войти в интерфейс SDDC Manager с использованием учётных данных VCF SSO невозможно — продолжайте использовать локальную учётную запись администратора, обычно administrator@vsphere.local.

Однако у SDDC Manager всё же есть конфигурация SSO, и её следует настроить для удалённого доступа к API. Это связано с тем, что после входа в vCenter Server некоторые действия, инициированные в vSphere Client, фактически выполняются SDDC Manager в фоновом режиме, и для этого потребуется аутентификация. Поэтому назначьте группе SSO, которую вы используете в vCenter Server, права администратора в SDDC Manager, чтобы обеспечить плавный и бесшовный доступ.

Практическая демонстрация

Если вы хотите увидеть полный процесс настройки VCF SSO, ознакомьтесь с этим короткой практической лабораторной работой (HOL), которая пошагово проводит через весь процесс: https://labs.hol.vmware.com/HOL/catalog/lab/26724.

Итоги

Новый релиз VMware Cloud Foundation привносит значительные изменения в рабочие процессы администраторов, особенно за счёт объединения множества административных и управленческих задач в новый интерфейс VCF Operations. Однако по-прежнему существуют специализированные консоли управления, к которым администраторам необходимо получать доступ. Теперь, благодаря VCF SSO и VIDB, переход к выполнению определённых действий в NSX Manager или vSphere Client стал значительно проще. Настройка VCF SSO лёгкая, а безопасность при этом не страдает благодаря интеграции с проверенными и надёжными провайдерами идентификации.

Вильям Лам написал интересный пост о методе автоматического присоединения к vCenter Server с использованием ESX Kickstart.

Недавно его упомянули в теме на Reddit, где обсуждалась автоматизация, над которой он работал более 14 лет назад. Тогда Вильям сделал скрипт, автоматически присоединяющий хост ESXi к vCenter Server с помощью ESXi Kickstart.

Решение с вызовом vSphere MOB и ручной генерацией XML-запроса для добавления хоста ESXi в нужный кластер vSphere в vCenter Server было, мягко говоря, неидеальным, но задачу оно выполняло. Сейчас это решение можно значительно улучшить, используя более современные подходы, при этом сохранив исходное требование: возможность добавить хост в кластер vSphere прямо из ESXi 8.x/9.x Kickstart без внешних зависимостей.

Шаг 1. Предполагаем, что у вас уже есть инфраструктура ESX Kickstart, готовая к работе.

Примечание: Для разработки Вильям настоятельно рекомендует использовать Nested ESXi и HTTP Boot через Virtual EFI — так вы сможете быстро протестировать автоматизацию ESX Kickstart перед тем, как развернуть её на реальном железе. Это позволит без особых усилий быстро создать рабочий прототип решения, которое вы увидите здесь.

Шаг 2. С помощью ChatGPT Вильяму удалось создать современную версию скрипта на основе Pyvmomi (vSphere SDK для Python), который использует тот же самый API vSphere для добавления хоста ESX в vCenter Server и его подключения к нужному кластеру vSphere. Скачайте скрипт add_host_to_cluster.py и разместите его на веб-сервере, с которого вы отдаёте конфигурацию ESX Kickstart, либо внедрите прямо в kickstart-файл.

Скрипт можно запускать локально на системе с установленным Pyvmomi или прямо на ESXi 8.x/9.x со следующим синтаксисом:

python add_host_to_cluster.py \
     --vcenter vc03.williamlam.local --vc-user '*protected email*' --vc-pass 'VMware1!' \
     --datacenter 'Datacenter' --cluster 'Cluster-01' \
     --host-user 'root' --host-pass 'VMware1!' --insecure --vmk vmk0

Шаг 3. Обновите ваш ESX Kickstart так, чтобы он запускал скрипт add_host_to_cluster.py с нужными параметрами. В данном примере и kickstart ESX, и скрипт add_host_to_cluster.py размещены на веб-сервере Вильяма, поэтому kickstart сначала загружает скрипт на хост ESX в рамках секции %firstboot, а затем запускает его с учётными данными для vCenter Server и хоста ESX, которые необходимы для вызова vSphere API.

Примечание: Скорее всего, вам НЕ следует использовать учётную запись администратора для добавления ESX-хоста. Вместо этого создайте сервисную учётную запись, у которой есть только права на добавление хостов в кластер vSphere и никакие другие роли, так как учётные данные придётся указывать в открытом виде (plain text).

vmaccepteula
rootpw VMware1!
install --firstdisk --overwritevmfs
network --bootproto=static --device=vmnic0 --ip=192.168.30.61 --netmask=255.255.255.0 --gateway=192.168.30.1 --hostname=esx01.williamlam.local --nameserver=192.168.30.29 --addvmportgroup=1
reboot

%firstboot --interpreter=busybox

# Ensure hostd is ready
while ! vim-cmd hostsvc/runtimeinfo; do
sleep 10
done

# Configure NTP
esxcli system ntp set -e true -s 10.0.0.221

# Enable HTTP Outbound
esxcli network firewall ruleset set -e true -r httpClient

# Add DNS Search Domain
esxcli network ip dns search add -d williamlam.local

# Download vSphere Cluster Host Add script
wget http://192.168.30.29/add_host_to_cluster.py -O /tmp/add_host_to_cluster.py

# Run Add Host script
python /tmp/add_host_to_cluster.py \
     --vcenter vc03.williamlam.local --vc-user '*protected email*' --vc-pass 'VMware1!' \
     --datacenter 'Datacenter' --cluster 'Cluster-01' \
     --host-user 'root' --host-pass 'VMware1!' --insecure --vmk vmk0

Вот скриншот итогового решения, где Вильям смог быстро продемонстрировать это с помощью виртуальной машины Nested ESXi и загрузки по HTTP через Virtual EFI (см. ссылку в Шаге 1). ESX устанавливается автоматически, так же как и на физической машине, а затем, в рамках пост-настройки, загружается наш скрипт на Pyvmomi и хост присоединяется к нужному кластеру vSphere:

Недавно компания Orion soft анонсировала релизы платформы виртуализации - zVirt 4.5 и zVirt 5.0. Давайте посмотрим, что нового обещает разработчик отечественной платформы виртуализации.

zVirt 4.5: вектор на производительность и виртуализацию сетей

По словам Orion soft, релиз 4.5 сфокусирован на двух крупных направлениях:

1. Рост производительности (внутренние оптимизации стека),
2. Дальнейшее развитие сетевой виртуализации (SDN). Это не «косметика», а серия внутренних апгрейдов, которые готовят почву под 5.0. Подробный перечень фич компания не публиковала, акцент именно на эти векторы развития.

Что это означает на практике:

• Ускорение «горячих» путей данных. В реальной эксплуатации это обычно выражается в уменьшении задержек операций ввода-вывода ВМ, росте пропускной способности при миграциях и репликации, а также в снижении накладных расходов управляющих сервисов. В контексте последних релизов zVirt компания уже поднимала потолок репликации и улучшала экспорт метрик/логов — версия 4.5 логично продолжает эту линию, но уже как «внутренний» апгрейд ядра платформы.
• Упрочнение SDN-стека. С версии 4.0/4.2 zVirt продвигал микросегментацию и управляемые сети через UI; в 4.5 ожидаем дальнейшее выравнивание производительности и функциональности SDN под крупные инсталляции (много проектов/сетей, избыточные связи, тонкая политика East-West). Идея — дать базис для грядущей миграции сетевых конфигураций из vSphere/NSX-подобных сценариев, заявленных к 5.0.

Вывод для архитекторов: 4.5 — это «подкапотный» релиз, который не меняет ваши процессы, но подготавливает площадку: стабильнее SDN, выше пропускная способность, а значит — меньше рисков при масштабировании кластеров и при переходе на версию 5.0.

zVirt 5.0: крупные продуктовые сдвиги

Для zVirt 5.0 Orion soft публично называл ряд ключевых возможностей, которые заметно расширяют зону автоматизации и упрощают миграцию с VMware-ландшафтов:

1. Storage DRS (распределение нагрузки по хранилищам)

Идеология — объединить несколько доменов хранения в логический «кластер» и автоматически балансировать размещение/миграцию дисков/ВМ по политикам (запас по IOPS/latency/ёмкости, «горячие» тома и т. п.). Это сокращает ручные операции, снижает риск «перекоса» томов хранения (LUN) и ускоряет реакцию на всплески нагрузки. Orion soft ранее уже демонстрировал Storage DRS в линейке 4.x, ну а в 5.0 ожидается консолидация и развитие этого направления как «функции по умолчанию» для больших инсталляций.

Практический эффект:

• Более предсказуемые SLA на уровне хранилища для VMs/VDIs.
• Упрощение сценариев расширения емкости (add capacity -> автоматический ребаланс).
• Меньше ручных миграций хранилищ в пиковые часы.

2. Упрощённый инсталлятор (быстрое развертывание/апгрейды)

Цель — сократить TTV (time-to-value): меньше шагов, больше проверок совместимости и готовности (сети, CPU-фичи, хранилища, сертификаты), шаблоны для типовых топологий (Hosted Engine, Standalone, edge-кластера). Это критично для массовых миграций с VMware: когда десятки площадок поднимаются параллельно, выигрыш в часах на площадку умножается на десятки.

3. Управление аппаратной репликацией на СХД

Речь о DR на уровне массивов (например, YADRO TATLIN.UNIFIED, Huawei Dorado и др.) с оркестрацией из консоли zVirt. Преимущества аппаратной репликации — RPO до 0 сек при синхронных схемах и низкая нагрузка на гипервизоры/SAN. План аварийного переключения становится «кнопкой» в едином UI. В 4.x уже были интеграции и демонстрации такого подхода, а версия 5.0 укрепляет это как нативный сценарий с централизованным управлением планами DR.

Практический эффект:

• Единый контрольный контур для DR (агентская и аппаратная репликации)
• Меньше конфликтов за ресурсы между продуктивом и DR-задачами
• Формализованные RTO/RPO для аудита

4. Terraform-провайдер

Провайдер позволяет декларативно описывать кластера, ВМ, сети/SDN-объекты, политики, хранилища — и воспроизводить их через CI/CD. Это даёт привычную для DevOps-команд «инфраструктуру как код» поверх zVirt, ускоряя создание однотипных стендов, DR-сайтов и «blue/green» сред.

Практический эффект:

• Контроль версий для инфраструктуры (git-история ваших кластеров)
• Воспроизводимость площадок (dev -> stage -> prod)
• Быстрый откат/повторение конфигураций по слияниям (merges).

5. Миграция конфигураций с VMware vSphere на SDN zVirt

Отдельно заявлена возможность импорта сетевых конфигураций из VMware-ландшафтов в SDN-модель zVirt: перенос порт-групп, сегментации, ACL/микросегментации и прочее. Это важная часть «бесшовной» стратегии импортозамещения: раньше боль была не только «перенести ВМ», но и воссоздать сетевую политику («зашитую» в vSphere/NSX). Версия 5.0 обещает автоматизировать этот пласт работ.

Практический эффект:

• Сокращение ошибок при ручном переносе сетей
• Предсказуемость инфраструктуры безопасности после миграции
• Ускорение cut-over окон при переездах больших ферм ВМ.

Как готовиться к zVirt 4.5/5.0 в производственной среде

1. Проверить лимиты и совместимость (ядра, CPU-фичи, сетевые карты, Mellanox/Intel, fabric-параметры, NUMA-profile, лимиты по миграциям/сетям/ВМ) — чтобы апгрейды прошли «в стык», без регрессий. Актуальные лимиты и best practices доступны в вики Orion soft.
2. Нормализовать SDN-модель: привести именование сетей/проектов к единому стандарту, сверить микросегментацию и схему ACL — это упростит будущий импорт конфигураций и policy-driven-балансировку. В версии 4.2 уже был сделан большой шаг по SDN/микросегментации.
3. Обновить процессы DR: если у вас есть массивы с аппаратной репликацией — инвентаризовать пары массивов, RPO/RTO, каналы межплощадочной связи; продумать, какие сервисы уйдут на аппаратную репликацию, а какие останутся на агентской (уровень гипервизора).
4. Заложить IaC-подход: начать описывать парки ВМ, сети, хранилища в Terraform (как минимум — черновые манифесты), чтобы к моменту выхода провайдера под 5.0 ваш репозиторий уже отражал фактическую инфраструктуру.

Более подробно о новых возможностях zVirt 4.5 и zVirt 5.0 можно почитать вот тут.

В рамках обновления инфраструктуры VMware Cloud Foundation 9 компания VMware обновила и свое основное средство для миграции физических и виртуальных машин на платформу VCF - vCenter Converter Standalone 9.0, про долгое отсутствие обновлений которого мы писали вот тут.

Давайте посмотрим, что нового в Converter девятой версии:

1. Поддержка VMware Cloud Foundation 9.0 и нового виртуального оборудования

• Версия 9.0 добавляет полную совместимость с VMware Cloud Foundation 9.0, что позволяет интеграцию с последним стеком VMware.
• Добавлена поддержка виртуального аппаратного обеспечения (virtual hardware) версии 22, обеспечивающего более широкие возможности и улучшенную производительность виртуальных машин.

2. Поддержка SSL-сертификатов

• Добавлена возможность использования полных SSL-сертификатов. Это серьёзный шаг в сторону безопасности, позволяющий использовать самоподписанные и централизованные сертификационные центры, улучшая защищённость соединений при миграции машин.

3. Усовершенствования в области безопасности: TLS-протоколы

• По умолчанию Converter 9.0 поддерживает только TLS 1.2, что соответствует современным стандартам безопасности.
• При необходимости возможно включение устаревших протоколов TLS 1.0 и TLS 1.1, однако делать это рекомендуется только в исключительных ситуациях.

4. Поддержка IPv6 и различных типов источников

• Теперь поддерживается IPv6, что позволяет выполнять конвертацию в современных сетевых инфраструктурах.
• Расширена поддержка типов источников: можно конвертировать удалённые работающие машины, выключенные виртуальные машины VMware и виртуальные машины на Hyper-V Server.

5. Улучшения удалённого доступа и клиент-серверной архитектуры

• Благодаря remote access, доступно создание и управление задачами конвертации удалённо — с удалённого клиента через клиент-серверную установку. Это значительно упрощает работу в распределённых средах.

Рекомендации по использованию

1. Обновите vCenter Converter Standalone до версии 9.0, чтобы воспользоваться новыми возможностями безопасности и совместимости.
2. Настройте SSL-сертификаты для защиты SSH- и API-трафика.
3. Проверьте конфигурацию сети, особенно если используется IPv6.
4. Используйте только TLS 1.2, если нет веских причин активировать устаревшие протоколы.
5. Настройте архитектуру клиент-сервер для эффективного управления задачами конвертации удалённо.

Ограничения

• Поддержка аутентификации с использованием алгоритмов RSA SHA1 устарела. Вместо этого рекомендуется использовать более новые алгоритмы или перейти на аутентификацию по паролю.
• vCenter Converter Standalone поддерживает исходные и целевые дисковые накопители только с размером сектора 512B (512e и 512n). Диски с нативным размером сектора 4K (4Kn) не поддерживаются.
• Начиная с версии vCenter Converter Standalone 9.0, конвертация файловых систем ReiserFS больше не поддерживается.

Supervisor Control Plane — это управляющий уровень встроенного Kubernetes (Supervisor Cluster) в решении VMware vSphere with Tanzu (ранее vSphere with Kubernetes). Он развёрнут как три виртуальные машины (Supervisor Control Plane VMs), которые выполняют контроль над кластером Kubernetes, включая etcd, API-сервер, контроллеры и планировщик. Важнейшие функции этих виртуальных машин:

• Интеграция с инфраструктурой vSphere: Supervisor Control Plane взаимодействует с ресурсами ESX-хостов — CPU, память, сеть, хранилище — и позволяет запускать контейнеры напрямую на гипервизоре (vSphere Pods).
• API-доступ: администраторы управляют кластерами через интерфейс vSphere Client и API vSphere with Tanzu, а разработчики — через kubectl.
• Высокая доступность: обеспечивается трёхкомпонентной архитектурой. Если один узел выходит из строя, другие продолжают работу.

Полезный трюк — как получить SSH-пароль для Supervisor Control Plane VM

Есть простой способ получить доступ по SSH для виртуальных машин, входящих в состав Supervisor Control Plane:

1. Подключитесь по SSH к виртуальному модулю сервера vCenter под пользователем root.
2. Выполните скрипт:

Скрипт выведет IP-адрес (обычно FIP, то есть "floating IP") и автоматически сгенерированный пароль. После этого вы можете подключиться по SSH к Supervisor Control Plane VM как root@<FIP> с полученным паролем.

Важно! Доступ к этим ВМ следует использовать только для диагностики и устранения проблем — любые изменения в них (особенно без одобрения от поддержки VMware) могут привести к нарушению работоспособности Supervisor-кластера, и поддержка может потребовать его полного развертывания заново.

Полезные рекомендации и предосторожения

• Скрипт /usr/lib/vmware-wcp/decryptK8Pwd.py извлекает пароль из базы данных vCenter. Он удобен для быстрого доступа, особенно при отладке сетевых или других проблем с Supervisor VM.
• Убедитесь, что FIP действительно доступен и корректно маршрутизируется. При сбое etcd FIP не назначится, и придётся использовать реальный IP-адрес интерфейса (например, eth0). Также при смене FIP удалите старую запись из known_hosts — сертификаты могут изменяться при «плавании» IP.
• Используйте доступ только для анализа, чтения логов и выполнения команд kubectl logs/get/describe.

На конференции VMware Explore 2025 компания Broadcom объявила, что службы VMware Private AI Services теперь входят в стандартную поставку VMware Cloud Foundation 9.0 (VCF 9.0). То есть VCF превращается в полноценную AI-native платформу частного облака: из коробки доступны (или будут доступны) сервисы для работы с моделями, наблюдаемость за GPU, среда исполнения для моделей и агент-фреймворк, плюс дорожная карта с MCP, multi-accelerator и AI-ассистентом для VCF.

Платформа VCF 9.0 уже находится в статусе General Availability и доступна с июня 2025, а выход служб Private AI Services в составе подписки планируется к началу первого квартала 2026 финансового года Broadcom.

Давайте посмотрим на состав и функции VMware Private AI Services:

Слой AI-сервисов в VCF 9.0

Что «входит по умолчанию» в Private AI Services (становится частью подписки VCF 9.0):

• GPU Monitoring — телеметрия и наблюдаемость графических карт.
• Model Store — репозиторий и версионирование моделей.
• Model Runtime — сервисный слой для развертывания/экспонирования моделей (endpoints).
• Agent Builder — сборка/оркестрация «агентов» поверх LLM.
• Vector Database & Data Indexing/Retrieval — индексация корпоративных данных и RAG-потоки.
  

Эти возможности поставляются как native services платформы, а не «надстройка» — и это важная архитектурная деталь: AI становится частью инфраструктуры, живущей в тех же сущностных/безопасностных доменах, что и виртуальные машины и контейнеры.

Также были анонсированы следуюие продукты и технологии в рамках дорожной карты:

• Intelligent Assist for VCF — LLM-ассистент для диагностики и самопомощи в VCF (пока как tech preview для on-prem/air-gapped и cloud-моделей).
• Model Context Protocol (MCP) — стандартная, управляемая интеграция ассистентов с инструментами и БД (Oracle, MSSQL, ServiceNow, GitHub, Slack, PostgreSQL и др.).
• Multi-accelerator Model Runtime — единая среда исполнения для AMD и NVIDIA GPU без переработки приложений; поддержка NVIDIA Blackwell, B200, ConnectX-7/BlueField-3 с технологией Enhanced DirectPath I/O.
• Multi-tenant Models-as-a-Service — безопасное шаринг-использование моделей между пространствами имен/линиями бизнеса.

Ядро VCF 9.0: что поменялось в самой платформе

Единая операционная плоскость

VCF 9.0 переносит фокус на «One interface to operate» (VCF Operations) и «One interface to consume» (VCF Automation): единая модель политик, API и общий движок жизненного цикла. Это снижает расхождение инструментов и обучаемость. На практике это дает унифицированное управление инфраструктурой, health/patch/compliance из одной консоли, централизованные функции IAM/SSO/сертификатов, анализ корреляции логов и другие возможности.

Примеры экранов и функций, доступных в VCF Operations: обзор по всем инстансам, геокарта, статус сертификатов с автообновлением, NetOps-дэшборды (NSX health, VPC, flows), интеграция Live Recovery и LogAssist.

Слой потребления (для разработчиков/проектных команд)

• GitOps (Argo CD) как встроенная модель доставки, Istio Service Mesh для zero-trust/observability трафика, единый контроль политик по проектам.
• vSphere Kubernetes Service (VKS) — функции enterprise-K8s, доступные прямо из VCF.
• Native vSAN S3 Object Store — S3-совместимый API хранилища объектов на vSAN, без внешних лицензий/модулей.

Все это — официальные «новые в 9.0» элементы, влияющие на скорость доставки сервисов и безопасность.

Производительность и эффективность

• NVMe Memory Tiering — расширение оперативной памяти за счет NVMe для высокочастотных/in-memory нагрузок.
• vSAN Global Deduplication (ESA) — постпроцессинговая глобальная дедупликация на уровне кластера.
• Улучшенные data paths + опциональный DPU offload — снижение задержек в east-west контуре, предсказуемость отклика.

• Security Operations Dashboard - непрерывный compliance-сканер (CIS/NIST/кастомные baselines), identity & cert management, «drift»-контроль.
• Встроенные chargeback/showback и cost dashboards (TCO-прозрачность, прогнозирование, возврат/reclaim неиспользуемых ресурсов).

Аппаратные улучшения/сетевой стек для AI

VCF 9.0 выравнивает работу «больших» AI-нагрузок на частной инфраструктуре:

• Поддержка NVIDIA Blackwell (включая RTX PRO 6000 Blackwell Server Edition, B200, HGX с NVSwitch), GPUDirect RDMA/Storage, Enhanced DirectPath I/O - при этом сохраняются «классические» возможности vSphere (vMotion, HA, DRS, Live Patching).
• Совместная работа с AMD: ROCm Enterprise AI и Instinct MI350 для задач fine-tuning/RAG/inference. Это не «плагин», а интегрированная часть VCF и экосистемы VMware Private AI Foundation with NVIDIA.

Как это интегрируется в вашм бизнес-процессы

Типовые сценарии, которые теперь проще закрывать «из коробки»:

• Models-as-a-Service: реестр -> развертывание -> публикация endpoint-ов -> контроль версий/квот -> многоарендность.
• Агенты поверх LLM: ускоренный старт с Agent Builder + подключение к корпоративным данным через индексирование/вектора.
• RAG-потоки с политиками и аудитом: источники данных под управлением VCF, контроль доступа на уровне платформы, видимость (observability).
• Доставка сервисов K8s: GitOps (Argo CD), сервис-меш (Istio), S3-объекты на vSAN для артефактов/данных.

Лицензирование/доставка и пути обновления

• GA: VCF 9.0 доступен с 17 июня 2025.
• Службы Private AI Services обещаны как часть подписки VCF 9.0 в Q1 FY26 от Broadcom.
• Официальный документ с фичами и путями миграции VCF <-> VVF 9.0 доступен тут.

Вывод

VCF 9.0 — это не просто «еще одна» версия с оптимизациями. За счет включения Private AI Services в базовую платформу и сдвига на «one interface to operate/consume», VCF превращает AI-нагрузки в основу частного облака, сохраняя корпоративные политики, комплаенс и привычные SRE-процессы — от GPU до GitOps.

VMware недавно объявила о выпуске пяти новых экзаменов для профессиональной сертификации, основанных на версии 9 их платформы Cloud Foundation. Эти сертификаты представляют собой значительную эволюцию в портфеле сертификаций VMware, отражая продолжающееся новаторство компании в области технологий Cloud Foundation и виртуализации под руководством Broadcom.

Новый пакет сертификаций включает специализированные направления как для VMware Cloud Foundation (VCF), так и для VMware vSphere Foundation (VVF), охватывая ключевые роли — от администрирования и поддержки до архитектуры. Каждая сертификация предназначена для подтверждения навыков, необходимых для управления современной облачной инфраструктурой, устранения неполадок и проектирования в корпоративной среде.

Обзор нового портфеля сертификаций

Итак, появилось пять новых сертификаций уровня VMware Certified Professional (VCP):

• VMware Certified Professional - VMware vSphere Foundation Support (2V0-18.25)
• VMware Certified Professional - VMware Cloud Foundation Administrator (2V0-17.25)
• VMware Certified Professional - VMware Cloud Foundation Support (2V0-15.25)
• VMware Certified Professional - VMware Cloud Foundation Architect (2V0-13.25)
• VMware Certified Professional - VMware vSphere Foundation Administrator (2V0-16.25)

Эти сертификации отвечают растущему спросу на квалифицированных специалистов, которые могут эффективно внедрять, администрировать, поддерживать и проектировать частные облака с использованием новейших технологий VMware. Каждый экзамен проводится в едином формате: 60 вопросов с несколькими вариантами ответов, продолжительность — 135 минут, проходной балл — 300, стоимость попытки — 250 долларов.

Подробное рассмотрение каждой сертификации

1. VMware Certified Professional - VMware vSphere Foundation Support (2V0-18.25)

Эта сертификация является важной стартовой точкой для ИТ-специалистов, стремящихся углубиться в поддержку и устранение неполадок в средах VMware vSphere Foundation (VVF). Она подтверждает владение стандартными методиками диагностики и устранения проблем, возникающих при развертывании и эксплуатации VVF. Экзамен охватывает архитектуру VVF, включая основные функции, компоненты и модели работы.

Ключевые технические области:

• Операции с VCF
• Администрирование vCenter Server
• Управление гипервизором VMware ESX
• Работа с хранилищами VMware vSAN
• VMware Operations для централизованного логирования и мониторинга

Эта сертификация ценна для специалистов, переходящих от традиционной поддержки инфраструктуры к поддержке облачных виртуализированных систем. Подготовка возможна по Exam Study Guide, регистрация — через портал Broadcom.

2. VMware Certified Professional - VMware Cloud Foundation Administrator (2V0-17.25)

Эта сертификация предназначена для ИТ-специалистов, ответственных за ежедневное администрирование и управление средами VMware Cloud Foundation (VCF). Она подтверждает навыки по развертыванию, управлению и поддержке частных облаков на базе VCF. Адресована системным администраторам, облачным администраторам и специалистам по инфраструктуре, переходящим от традиционных ролей к обязанностям в области облачных технологий.

Основные темы: развертывание, администрирование, оптимизация производительности, настройка безопасности и устранение неполадок. Рекомендуемые курсы:

• VMware Cloud Foundation: Build, Manage, and Secure
• VMware Cloud Foundation: Automate and Operate

Подготовка — через Exam Study Guide, регистрация — в официальном портале Broadcom.

3. VMware Certified Professional - VMware Cloud Foundation Support (2V0-15.25)

Эта сертификация фокусируется на специалистах поддержки VMware Cloud Foundation. Она подтверждает умение диагностировать и устранять проблемы в частных облаках на базе VCF. Подходит для тех, кто переходит от традиционной поддержки инфраструктуры к ролям Cloud support или Site Reliability Engineer (SRE).

Сертификация охватывает:

• Продвинутые методики диагностики
• Инструменты анализа производительности
• Стратегии устранения сложных инцидентов

Рекомендуемый курс: "VMware Cloud Foundation: Troubleshooting". Доступны Exam Study Guide и регистрация через портал Broadcom.

4. VMware Certified Professional - VMware Cloud Foundation Architect (2V0-13.25)

Это наиболее продвинутая сертификация уровня VCF, подтверждающая навыки архитектурного проектирования решений VMware Cloud Foundation. Она ориентирована на архитекторов инфраструктуры и консультантов, которые разрабатывают масштабируемые, отказоустойчивые и безопасные решения.

Основные темы:

• Методологии проектирования
• Планирование ёмкости
• Высокодоступные и отказоустойчивые архитектуры
• Безопасность и интеграция с существующей инфраструктурой.

Рекомендуемый курс: "VMware Cloud Foundation: Solution Architecture and Design". Подготовка — по Exam Study Guide, регистрация — через портал Broadcom.

5. VMware Certified Professional - VMware vSphere Foundation Administrator (2V0-16.25)

Эта сертификация подтверждает компетенции специалистов, администрирующих среды VMware vSphere Foundation (VVF). Она охватывает:

• Развертывание и конфигурацию
• Администрирование виртуальных машин
• Распределение ресурсов
• Мониторинг производительности
• Настройку безопасности и устранение неполадок

Сертификация ориентирована на администраторов виртуальных сред. Рекомендуемый курс: "vSphere Foundation: Build, Manage and Secure". Подготовка — через Exam Study Guide, регистрация — на портале Broadcom.

Заключение

Запуск пяти новых сертификаций отражает стремление VMware укреплять лидерство в области облачных технологий. Они позволяют ИТ-специалистам строить карьеру в направлениях поддержки, администрирования и архитектуры. В версии 9 сертификации учитывают последние возможности и лучшие практики, что особенно важно в условиях быстрого развития технологий. Каждая сертификация обеспечивает уникальный путь профессионального развития и подтверждает как технические навыки, так и стремление к постоянному обучению.

Оптимальная ИТ-инфраструктура характеризуется способностью поддерживать растущее количество рабочих нагрузок со временем и управлять колебаниями требований к ресурсам в реальном времени при сохранении максимальной производительности. VMware Cloud Foundation 9 облегчает внедрение облачной операционной модели в масштабах организации, тем самым ускоряя гибкость ИТ, повышая масштабируемость инфраструктуры, улучшая безопасность и снижая совокупную стоимость владения.

Наступают интересные времена для автоматизации облачной инфраструктуры - платформа VMware Cloud Foundation (VCF) 9.0 уже здесь, и она готова революционизировать подход к частному облаку. В основе VCF 9.0 лежит решение VCF Automation 9, обеспечивающая удобный опыт работы с частным облаком в рамках рабочих процессов самообслуживания.

Этот релиз привносит множество новых возможностей автоматизации облачной инфраструктуры, которые помогут ускорить инновации в приложениях, снизить затраты и масштабировать управление и соответствие требованиям - как никогда раньше.

Давайте рассмотрим три революционных инновации в проектировании частного облака, которые уже доступны.

1. IaaS для частного облака в стиле публичного облака прямо "из коробки"

Современный облачный интерфейс

Потребители частного облака — включая разработчиков, инженеров DevOps и платформенных инженеров - будут рады тому, что VCF обеспечивает опыт потребления, аналогичный публичному облаку, для команд, создающих приложения в защищённой частной среде с поддержкой GPU (AI), Kubernetes, защиты данных, сетевых сервисов Virtual Private Cloud (VPC), которые предоставляются напрямую через базовую платформу vSphere в рамках Modern Cloud Interface.

Modern Cloud Interface открывает новые сервисы частного облака (подобные сервисам публичного облака) по всем окружениям VCF / vCenter и агрегирует их в единый общий эндпоинт, который может быть использован через различные интерфейсы: графический UI, CLI или декларативный Kubernetes IaaS API для самообслуживания. VCF Automation абстрагирует ресурсы во всех окружениях VCF и предоставляет единый интерфейс потребления.

Сервисы частного облака

Основные облачные сервисы, доступные «из коробки», включают: виртуальные машины (VM), vSphere Kubernetes Service (VKS), сеть, тома хранения и образы виртуальных машин. Команды разработчиков, DevOps и инженеров платформы могут использовать Modern Cloud Interface для потребления любых ресурсов через Kubernetes IaaS API на Supervisor, включая сервис VKS для развертывания кластеров Kubernetes и VM Service, позволяющий декларативно описывать и создавать виртуальные машины, и многое другое.

Команды приложений, предпочитающие использовать Kubernetes для оркестрации приложений, по достоинству оценят гибкость и адаптируемость VCF Automation. Они могут использовать K8s-манифесты для развертывания виртуальных машин и кластеров VKS (как объектов K8s), что обеспечивает более гибкий и оперативный процесс разработки. Также доступны действия второго дня (Day-2), например, масштабирование кластеров VKS, включение/выключение виртуальных машин и т. д. Такой уровень контроля вселяет уверенность и обеспечивает более эффективное управление.

VCF Automation: сервис виртуальных машин (VM Service) настраивается через UI и YAML-манифесты ресурсов K8s.

VCF Automation: сервис VKS настраивается через UI и YAML-манифесты ресурсов K8s.

Кроме того, в то время как публичные облака просто предоставляют вам стандартный upstream-кластер Kubernetes, на который вы устанавливаете своё приложение (EKS, AKS, GKE), VCF идёт дальше. VMware продолжает добавлять новые расширяемые сервисы — службы частного облака, расширяющие платформу VCF. К расширяемым сервисам относятся: хранилище образов Harbor, контроллер входящего трафика Contour Kubernetes Ingress Controller, служба сертификатов cert-manager, Istio Service Mesh, ExternalDNS, оператор Data Services Manager (DSM) Consumption, Secret Store и т.д.

Администратор корпоративной инфраструктуры может активировать эти сервисы на Supervisor, включив сертифицированные операторы или сервисы, и тем самым сделать их легко доступными. Команды приложений могут развертывать, управлять и изменять эти конструкции — например, создавать базу данных в DSM или развернуть Postgres БД и т.п.

:

Проектирование (Blueprinting) и инфраструктура как код

Кроме того, в VCF Automation реализован подход blueprinting, который помогает интегрировать различные задачи. Blueprint — это настраиваемый шаблон, в котором вы определяете виртуальные машины, сеть, хранилище и другие инфраструктурные ресурсы для своей среды. Платформенные инженеры могут использовать визуальное дизайнерское полотно и возможности Infrastructure as Code, чтобы создать целостную процедуру. Это может включать развертывание виртуальных машин, кластеров VKS и развертывание приложений на этих ресурсах. Инженеры также могут реализовать рабочую станцию AI с поддержкой GPU и возможностями RAG (Retrieval-Augmented Generation). Blueprint’ы могут находиться под управлением системы контроля версий и храниться в репозиториях, таких как GitHub, GitLab или Bitbucket. Кроме того, их можно публиковать в каталоге самообслуживания, чтобы разработчики и инженеры DevOps могли получать к ним доступ.

ИТ-команды могут наделить команды разработчиков возможностью получать инфраструктуру тогда, где и как им это нужно, что повышает продуктивность разработчиков и удовлетворённость пользователей.

2. Изолированные частные облака для каждой из ваших организаций

Управление арендаторами (Tenant Management)

Стать собственным провайдером облака стало гораздо проще. VCF Automation внедряет новые возможности управления арендаторами. Через Provider Portal администраторы могут выделять ресурсы, изолировать инфраструктуру и сегментировать сети с помощью VPC, создавая изолированные частные облака для каждой из организаций. Новые возможности мульти-арендности помогают обеспечить безопасность, предотвращая несанкционированный доступ или взаимодействие между разными группами пользователей или ресурсами.

Звучит сложно? Не стоит беспокоиться. В VCF 9.0 VCF Automation был переработан, чтобы упростить переход администраторов к масштабированию мультиарендного частного облака. Интерфейс теперь основан на намерениях и построен вокруг зон Manage & Govern, Build & Deploy и Administer.

VCF Automation предоставляет упрощённый способ начать создание окружения с помощью мастера быстрого запуска (quick start wizard). Например, администратор (Enterprise IT Admin), не имеющий опыта работы с мультитенантностью, может быстро и легко начать настройку организаций (тенантов) как облачный провайдер через мастер. Пошаговые процессы помогают администраторам понять, какие облачные концепции / конструкции управления и конфигурации необходимы, что позволяет им эволюционировать в "облачных администраторов".

Следуя пошаговому мастеру, администратор может настроить одну Организацию для типичного предприятия или несколько Организаций — для компаний, которым требуется изоляция инфраструктуры. Кроме того, он может выделять ресурсы и назначать квоты инфраструктуры для каждой Организации.

Затем администратор организации (Org Admin), отвечающий за управление конкретной Организацией, может создать Проект(ы) через портал Организации. Проекты можно создавать для различных бизнес-направлений (LOB) (например, бизнес-подразделения, команды приложений и т. д.) внутри Организации, и ими управляют LOB-администраторы. Org Admin также может настроить управление доступом (Identity Access Management). Это позволяет логически группировать несколько LOB-пользователей внутри Организации и применять согласованные политики управления для групп с похожими потребностями, упрощая контроль и безопасность.

Org Admin создаёт пространства имен (Namespaces - ресурсные контейнеры, определяющие лимиты ресурсов — CPU, память и хранилище для рабочих нагрузок) с использованием шаблонов Namespace Classes. Далее Org Admin выбирает VPC (домены сетевой изоляции) для создания пространств имен. Каждому пространству можно назначить одну или несколько VPC, которые могут использоваться совместно между несколькими пространствами имен, позволяя командам приложений использовать общую сеть, если необходимо.

Project Namespaces позволяют Org Admin-ам организовывать приложения и рабочие нагрузки по бизнес-назначению и владельцам, что облегчает применение различных политик безопасности и операционного контроля по приложениям/рабочим нагрузкам и средам.

После того как все окружения настроены, VCF предоставляет Enterprise IT Admin-ам, Org Admin-ам и LOB Admin-ам новые возможности Tenant Operations для упрощения управления и потребления инфраструктурных ресурсов. Enterprise IT Admin получает обзор всей ИТ-инфраструктуры через VCF Operations — видит все созданные Организации, общую ёмкость инфраструктуры и общую стоимость частного облака.

Org Admin может отслеживать свою конкретную Организацию, Проекты, Namespaces, политики и пользователей через портал Организации. Он может мониторить общее использование вычислительных ресурсов, памяти и хранилища. Такая расширенная видимость потребления облачной инфраструктуры (операционные метрики из VCF Operations) позволяет принимать более обоснованные решения и проактивно управлять ресурсами на уровне предприятия и вплоть до уровня отдельных проектов.

Управление контентом

Управление и совместное использование стандартизированного контента между Организациями и Проектами стало намного проще.

• Централизованное управление библиотеками контента

Хорошая новость - время pub/sub-модели и хаотичной синхронизации ушло в прошлое. Благодаря новым возможностям управления контентом, Enterprise IT Admin может централизовать управление библиотеками контента в VCF Automation, вместо того чтобы управлять ими на множестве серверов vCenter. Теперь можно легко обнаруживать, создавать и назначать библиотеки контента непосредственно в VCF, что устраняет сложность и упрощает управление.

VCF Automation обнаруживает все библиотеки контента во всех vCenter и автоматически синхронизирует их в фоновом режиме. В версии VCF 9.0 вы также можете создавать новые библиотеки контента прямо в VCF Automation, добавлять в них один или несколько образов виртуальных машин и назначать их одной или нескольким Организациям по мере необходимости. Это позволяет распределять существующие или новые образы ВМ и/или библиотеки контента между несколькими Организациями. Более того, можно использовать одну и ту же библиотеку контента в нескольких vCenter для определённых регионов, что позволяет масштабировать управление контентом.

• Использование Content Hub для управления и публикации контента

Также в VCF 9.0 появился Content Hub, предназначенный для Org Admin-ов и LOB Admin-ов, где можно управлять контентом в одном месте и публиковать его в каталог самообслуживания одним кликом, упрощая распространение и управление контентом. Через Content Hub администраторы могут централизованно управлять ресурсами, такими как библиотеки контента, образы ВМ, blueprints и рабочие процессы оркестрации. Всё это можно удобно организовать в одном месте, упрощая совместное использование между различными проектами.

Это повышает эффективность и производительность, сокращая трудозатратные ручные операции, связанные с управлением контентом между различными группами пользователей (например, поиском нужных ресурсов и выяснением, кто чем пользуется). Org Admin и LOB Admin могут эффективно управлять и обновлять контент, обеспечивая команды приложений актуальными стандартизированными ресурсами, которые можно потреблять самостоятельно и независимо.

3. Простое управление благодаря встроенным "ограничителям" (guardrails)

Пора избавиться от необходимости использовать разные инструменты для управления политиками. VCF Automation 9.0 позволяет Org Admin-ам создавать собственные политики для IaaS-ресурсов, используя новый YAML-формат Policy as Code прямо в платформе VCF — без необходимости в сторонних инструментах или расширениях.

Новые политики для IaaS-ресурсов основаны на нативной технологии Kubernetes Validating Admission Policy, что упрощает контроль использования ресурсов виртуальными машинами и кластерами VKS по различным Организациям и пространствам имен в vSphere.

Это становится особенно мощной возможностью для Org Admin-ов, когда Enterprise IT Admin включает самообслуживаемое развертывание кластеров VKS в мульти-тенантной среде. Org Admin может программно применять политики на уровне инфраструктуры, последовательно во всей Организации или для конкретных Проектов.

Политики для IaaS-ресурсов в формате "policy as code" не только масштабируют процессы управления и контроля, но также снижают риск человеческих ошибок и обеспечивают соответствие инфраструктурных ресурсов требованиям организации, повышая уровень комплаенса. Org Admin-ы, не имеющие опыта работы с policy as code, могут использовать новые предопределённые шаблоны политик, доступные «из коробки» в VCF Automation, чтобы быстро начать централизованное управление ресурсными политиками.

Единый опыт потребления облака

Инновации VCF Automation в версии VCF 9.0 реализуют ключевые преимущества, важные для современных предприятий, использующих рабочие нагрузки на основе виртуальных машин и контейнеров — особенно в условиях стремительного роста внедрения AI. Платформа VCF обеспечивает простоту управления всей инфраструктурой как единым облаком. Она сочетает гибкость и масштаб публичного облака с безопасностью и производительностью частного. Благодаря ориентации на потребности команд приложений, VCF 9.0 превращает инфраструктуру в единое, бесшовное облако, которое удобно потреблять — ускоряя инновации в области приложений.

Data Services Manager (DSM) 9.0 теперь доступен, и организации стремятся понять, как использование этого дополнения к VMware Cloud Foundation (VCF) может помочь им в реализации решения DBaaS в локальной среде. В этом посте будут рассмотрены убедительные преимущества DSM, адаптированные для трех различных ролей: администратора, DBA и конечного пользователя/разработчика.

Преимущества DSM для администратора виртуальной инфраструктуры

Контроль размещения и отказоустойчивости

Прежде всего, этот продукт разработан с учетом требований администратора виртуальной инфраструктуры. Цель была помочь ему контролировать «разрастание данных» и сохранять контроль над размещением баз данных и сервисов данных в инфраструктуре vSphere. Это достигается посредством конструкции DSM, называемой политикой инфраструктуры. Она определяет, какие вычислительные ресурсы, хранилище, сети и даже какая папка ВМ используются для размещения конкретной базы данных. Это не только упрощает общее управление и использование инфраструктуры, но также помогает с контролем лицензирования, прогнозированием, биллингом и т. д. Такое размещение и контроль становятся еще более детализированными с VCF 9.0, где DSM может использовать политику инфраструктуры на основе пространства имен vSphere для развертывания баз данных и сервисов данных. Администратор создает пространства имен vSphere в Supervisor. Как администратор vSphere, он устанавливает лимиты на CPU, память и хранилище в пространстве имен vSphere.

Через политику инфраструктуры администратор также может определить отказоустойчивость базы данных. В то время как DBA может выбрать, будет ли база данных автономной (один узел) или кластерной (три узла), политика инфраструктуры определит размещение кластерной базы данных с точки зрения vSphere. По умолчанию DSM разместит три виртуальные машины кластерной базы данных на разных хостах ESX в одном кластере vSphere. Однако администратор также может создать межкластерную политику инфраструктуры, которая, будучи выбранной DBA, разместит разные узлы одного и того же кластера базы данных в разных кластерах vSphere, обеспечивая еще более высокий уровень доступности.

Видимость и аналитика

Хотя DSM имеет собственный интерфейс и API, не хотелось бы, чтобы администратор «переключался» между разными интерфейсами при мониторинге баз данных и сервисов данных, развернутых DSM на vSphere. Поэтому VMware интегрировала в клиент vSphere возможность просмотра сведений о базах данных и сервисах данных. С одного взгляда администратор может увидеть список развернутых баз данных, имя экземпляра базы, тип движка (Postgres, MySQL, MS SQL) в клиенте vSphere, а также статус БД, версию, уровень оповещений, число узлов, отказоустойчивость, политику инфраструктуры, политику хранения и т. д. Администраторы могут перейти к более детализированному просмотру и увидеть соответствующее имя виртуальной машины, сведения о размещении, а также использование CPU, памяти и дисков. Хотя это само по себе полезно для администратора, это также чрезвычайно полезно для обсуждений между администраторами и DBA по всем аспектам инфраструктуры, потребляемой базой данных, когда требуется понять использование ресурсов, производительность, масштабирование и другие характеристики. Пример такого представления приведен ниже.

Интеграция с vSphere и VMware Cloud Foundation

DSM интегрируется с основными инфраструктурными продуктами vSphere. В предыдущем параграфе мы упомянули, что администратор может просматривать сведения о базах данных через клиент vSphere. Однако также имеется интеграция с Aria Automation 8.x для тех клиентов, которые хотят использовать этот уровень интеграции. DSM поставляется с пользовательским ресурсом для Aria Automation, который после установки создает элемент каталога сервисов для поддержки DBaaS. DSM 9.0 также интегрируется с VCF Automation. Администраторы могут создавать политики службы данных и назначать эти политики различным организациям для полноценного multitenant опыта DBaaS.

Аналогично осуществляется интеграция с Aria Operations, куда DSM и соответствующие базы данных могут отправлять свои метрики. За последние несколько лет была проделана работа по этим интеграциям, включая создание ряда стандартных панелей мониторинга для различных баз данных. Также в версии VCF 9.0 значительно улучшили мониторинг баз данных - теперь все метрики отправляются в VCF Operations. Более того, метрики теперь могут отправляться из DSM 9.0 в эндпоинт Prometheus для тех клиентов, которые хотят это использовать.

Наконец, в этой секции выделим еще одну интеграцию — с Aria Operations for Logs. В один шаг DSM может отправлять все журналы как из самого DSM-апплаенса, так и из всех его баз данных в единую целевую точку. Эти журналы могут отправляться на любой SYSLOG-эндпоинт.

Все вышеперечисленные точки интеграции должны быть полезны для администраторов, использующих полный стек VCF.

Поддержка

Поддержка Broadcom охватывает управление жизненным циклом движков данных, управляемых DSM, включая развертывание, обновление ОС и программного обеспечения базы данных, масштабирование и кластеризацию. Поддержка самого движка PostgreSQL или MySQL, включая, но не ограничиваясь исправлением ошибок, проблемами производительности и устранением уязвимостей, осуществляется сообществом upstream, при этом Broadcom оказывает содействие по принципу "best-effort".

Кроме того, VMware работает с сообществом с открытым исходным кодом, чтобы предоставить полноценное исправление downstream для любых ошибок, обнаруженных клиентами. Хотя VMware не может гарантировать, когда конкретное исправление будет доступно в какой-либо из баз данных с открытым исходным кодом, они могут создавать пользовательские сборки с исправлениями, которые еще не доступны в версиях open source. Это распространенная модель поддержки для продуктов с открытым исходным кодом, и многие поставщики DBaaS используют ту же модель. Это должно дать клиентам уверенность при выборе DSM для их DBaaS решения.

Преимущества DSM для DBA

Теперь сосредоточимся на DBA и тех преимуществах, которые DSM приносит этой роли.

Интуитивно понятный интерфейс для управления парком БД

DSM предоставляет DBA единую панель управления, которая позволяет легко управлять всем парком баз данных. Ниже показана страница по умолчанию для администраторов DSM с различными параметрами управления и конфигурации.

Управление жизненным циклом

Команда DSM регулярно предоставляет обновления для DSM. Это включает обновления для виртуального модуля DSM, гостевой ОС, используемой узлами базы данных, версий Kubernetes в этих узлах, а также собственно самих баз данных. Единственное, что требуется от DBA — загрузить и подготовить обновление. Как для виртуального модуля, так и для баз данных доступны окна обслуживания. Если обновление подготовлено, и наступает окно (обычно в ночь с субботы на воскресенье), обновление применяется автоматически. Никому не нужно вручную управлять жизненным циклом ОС виртуальных машин или кластера K8s — DSM делает это автоматически. Этот аспект часто упускается при сравнении DSM с другими решениями DBaaS.

Еще один важный момент — DSM теперь умеет обновлять как основные (major), так и минорные версии базы данных. Хотя при мажорный обновлениях DBA должен проявлять осторожность (например, проверить совместимость расширений), наличие такой возможности является значительным преимуществом.

Автоматизированные резервные копии и восстановление к точке во времени

Как и управление жизненным циклом, резервное копирование может быть автоматически настроено на этапе развертывания базы данных. Если эта опция включена, DSM начнет выполнять резервные копии сразу после включения базы данных. По умолчанию для Postgres раз в неделю выполняется полный бэкап. Ежедневные бэкапы выполняются каждый день, а журналы WAL отправляются каждые 5 минут или по достижении 16 МБ — что произойдет раньше. Для MySQL и MS SQL Server существуют собственные расписания по умолчанию. Благодаря такому автоматизированному расписанию резервного копирования доступны восстановления к точке во времени для всех баз данных.

Масштабирование — In / Out / Up / Down

DSM позволяет DBA легко масштабировать топологии баз данных — от автономного узла до трехузлового кластера и обратно. Также допускается вертикальное масштабирование, путем смены класса виртуальной машины, что увеличивает доступные CPU и память. И наоборот — если ресурсы остаются неиспользованными, DBA может уменьшить класс ВМ и сократить потребление ресурсов. Это особенно полезно, например, для закрытия месяца, квартала или во время “Black Friday”, когда базе данных временно требуются дополнительные ресурсы. После окончания «пика» ресурсы можно освободить.

Клонирование

DSM позволяет DBA создавать клоны базы данных, если возникает такая необходимость. Это полезно для тестовых и девелоперских сред, когда разработчики хотят запускать запросы на «живых» данных, не затрагивая продуктивную базу.

Интеграция с LDAPS

DSM поддерживает защищенный LDAP как для доступа к самому DSM, так и к базам данных. Это делает назначение прав доступа более безопасным и удобным. При развертывании базы данных DBA может выбрать интеграцию с Directory Service и затем с помощью простого оператора GRANT предоставить LDAP-пользователям доступ к базе. Кроме того, DSM поддерживает защищенный LDAP и для собственного UI, что позволяет пользователям и разработчикам (при наличии прав) самостоятельно создавать базы данных через DSM-интерфейс. Поддерживаются как ticket-based, так и self-service подходы.

Управление сертификатами

Для обеспечения защищенного доступа к базе данных необходимы сертификаты. DSM предоставляет два варианта — использовать собственные самоподписанные сертификаты DSM или загрузить пользовательские сертификаты. DBA может применить сертификаты как при создании базы, так и после ее развертывания. UI и API DSM делают процесс добавления сертификатов очень простым. С учетом современных требований безопасности — это крайне важная функция.

Аудит и оповещения

DSM предоставляет различные механизмы для оповещений, а также встроенные функции в UI. Оповещения могут отправляться по электронной почте (SMTP), а также через webhook-механизм в сторонние системы, такие как ServiceNow или Slack. Таким образом, DBA-команда никогда не пропустит важное событие.

Для целей соответствия требованиям, DSM ведет аудит событий, который DBA может быстро просмотреть. В версии DSM 9.0 журналы аудита также передаются на настроенную систему получения логов.

Высокая отказоустойчивость

Хотя это может показаться зоной ответственности администратора, именно DBA выбирает нужный уровень отказоустойчивости при создании базы. Эти параметры управляются через инфраструктурные и storage-политики. Как упоминалось ранее, кластерные базы могут быть размещены либо в одном кластере vSphere, либо распределены по разным кластерам. DBA выбирает нужный вариант, выбирая соответствующую политику.

Шифрование

Для шифрования можно использовать функцию VM Crypt, что позволяет шифровать отдельные базы данных. Это определяется в политике хранения, входящей в инфраструктурную политику. Альтернативно можно шифровать весь datastore (например, vSAN), и тогда любая база, размещенная на нем, будет автоматически зашифрована. Оба подхода поддерживаются DSM.

Отказоустойчивость и репликация

DBA может использовать репликацию для удаленной защиты базы. При наличии нескольких сред vSphere вторичный узел Postgres может быть размещен в другой среде vSphere с другим экземпляром DSM. В UI доступны элементы управления для повышения вторичного узла в первичный и наоборот. В случае потери целой среды vSphere можно выполнить восстановление баз данных в другую среду и продолжить работу.

Host-based access при развертывании

Файл pg_hba.conf в Postgres определяет, какие пользователи из каких сетей могут обращаться к базе. Через UI DSM DBA может заранее задать правила доступа при развертывании, не заходя в базу после ее создания. Это предотвращает ситуацию, когда база находится в «незащищенном» состоянии, пока эти правила не будут вручную настроены.

Расширенные параметры при развертывании

Аналогично предыдущему пункту, DBA может задать расширенные параметры при создании базы, не выполняя это как отдельный пост-шаг. Это сокращает время развертывания.

Защита от удаления

Пользователи DSM могут восстановить базу данных после ее удаления. Период хранения удаленной базы составляет 30 дней, но может быть уменьшен или увеличен при необходимости.

Преимущества DSM для конечного пользователя/разработчика

Одной из основных задач DSM является обеспечение модели самообслуживания DBaaS. Поэтому DSM предоставляет конечным пользователям и разработчикам простой механизм для запроса и доступа к базам данных. Рассмотрим эти возможности далее.

Интуитивно понятный интерфейс

Пользователи DSM получают очень простой интерфейс, позволяющий легко создавать, обновлять и удалять базы данных по мере необходимости. Они не видят настроек конфигурации и не видят базы данных других пользователей. Для тех конечных пользователей, которые предпочитают UI для развертывания баз, это интуитивно понятный и простой процесс.

Kubernetes и REST API

VMware понимает, что многие разработчики предпочитают не использовать пользовательский интерфейс. В некоторых случаях развертывание базы данных является частью более крупного CI/CD-пайплайна для тестирования. В связи с этим DSM предоставляет как API для Kubernetes, так и REST API. Это позволяет автоматизировать развертывание баз данных через DSM. API доступны на официальном сайте DSM API.

Развертывание баз DSM из удалённых K8s-кластеров

Многие разработчики уже используют Kubernetes для разработки приложений. Эти кластеры могут быть ограничены по ресурсам, например, использовать только локальное хранилище. Кроме того, SRE-команды сталкиваются с проблемой того, что разработчики создают «неконтролируемые» базы данных и сервисы данных, что приводит к конфликтам по ресурсам и вопросам соответствия. Благодаря Consumption Operator в DSM разработчики могут создавать собственные базы данных DSM на инфраструктуре vSphere и подключаться к ним из своих Kubernetes-кластеров.

Итог

Data Services Manager приносит много полезных функций в VCF. DSM предоставляет DBaaS-решение для VCF с той же поддержкой, что и сам VCF. DSM уже работает в производственной среде и в масштабах, управляемых Broadcom IT на протяжении последнего года (вся разработка Broadcom использует DBaaS через DSM на VCF). У Broadcom также есть множество крупных клиентов, реализующих аналогичные сценарии. Надеемся, этот обзор преимуществ DSM был для вас полезен, и вы рассмотрите возможность использования его в своей среде VCF.

Весной этого года вышел новый релиз бесплатной утилиты SexiGraf (Overwatch Nexus), предназначенной для мониторинга виртуальной инфраструктуры VMware vSphere. В последний раз мы писали об этом средстве в октябре прошлого года. Этот продукт был сделан энтузиастами (Raphael Schitz и Frederic Martin) в качестве альтернативы платным решениям для мониторинга серверов ESX и виртуальных машин. Представления SexiPanels для большого числа метрик в различных разрезах есть не только для VMware vSphere и vSAN, но и для ОС Windows и FreeNAS.

Что нового

• VMware vSAN Inventory — расширенная инвентаризация объектов vSAN.
• PowerShell Core 7.4.6 LTS — обновление среды скриптов.
• Ubuntu 22.04.5 LTS — современная версия операционной системы.
• Apache 2.4.63 — обновлённый веб-сервер.

Улучшения и исправления

• Возможность добавления SSH-ключа при деплое — повышает безопасность и удобство разграничения доступа.
• Добавлен сбор события DrsSoftRuleViolationEvent в event-коллектор — расширение мониторинга нарушений правил DRS.
• Исправлено неконсистентное значение GuestId в инвентаре VM (различие между vmx и vmtools) — повышение точности данных.
• Различные багфиксы — общее улучшение стабильности и надежности.

Миграция и формат поставки

SexiGraf с этой версии доступен исключительно в виде нового OVA-образа, обновления в виде патчей больше не выпускаются (за исключением экстренных случаев). Чтобы обновиться, пользователи должны:

1. Экспортировать данные из текущего SexiGraf-модуля.
2. Импортировать данные в новый OVA-модуль через функционал Export/Import.

Виртуальный модуль SexiGraf 0.99l уже доступен для загрузки и развёртывания. Установка происходит стандартным способом через OVA (например, через vSphere, OVF Tool и т.п.). Версия поддерживает переопределение root-пароля и SSH-ключа на этапе деплоя, что упрощает настройку и повышает безопасность.

Недавно компания VMware опубликовала полезный для администраторов документ «vSphere 9.0 Performance Best Practices» с указанием ключевых рекомендаций по обеспечению максимальной производительности гипервизора ESX и инфраструктуры управления vCenter.

Документ охватывает ряд аспектов, начиная с аппаратных требований и заканчивая тонкой настройкой виртуальной инфраструктуры. Некоторые разделы включают не всем известные аспекты тонкой настройки:

• Аппаратное обеспечение: CPU, память, дисковая подсистема, безопасность.
• Настройки BIOS: рекомендуется включить AES-NI, правильно сконфигурировать энергосбережение (например, «OS Controlled Mode»), при необходимости отключить некоторые C-states в особо чувствительных к задержкам приложениях.
• vCenter и Content Library: советуют минимизировать автоматические скриптовые входы, использовать группировку vCenter для повышения синхронизации, хранить библиотеку контента на хранилищах с VAAI и ограничивать сетевую нагрузку через глобальный throttling.
• Тонкое администрирование: правила доступа, лимиты, управление задачами, патчинг и обновления (включая рекомендации по BIOS и live scripts) и прочие глубокие настройки.

Отличия от версии для vSphere 8 (ESX и vCenter)

Аппаратные рекомендации

• vSphere 8 предоставляет рекомендации по оборудованию: совместимость, минимальные требования, использование PMem (Optane, NVDIMM-N), vPMEM/vPMEMDisk, VAAI, NVMe, сетевые настройки, BIOS-опции и оптимизации I/O и памяти.
• vSphere 9 добавляет новые аппаратные темы: фокус на AES-NI, snoop-режимах, NUMA-настройках, более гибком управлении энергопотреблением и безопасности на уровне BIOS.

vMotion и миграции

• vSphere 8: введение «Unified Data Transport» (UDT) для ускорения холодных миграций и клонирования (при поддержке обеих сторон). Также рекомендации для связки encrypted vMotion и vSAN.
• vSphere 9: больше внимания уделяется безопасности и производительности на стороне vCenter и BIOS, но UDT остаётся ключевым механизмом. В анонсах vSphere 9 в рамках Cloud Foundation акцент сделан на улучшенном управлении жизненным циклом и live patching.

Управление инфраструктурой

• vSphere 8: рекомендации по vSphere Lifecycle Manager, UDT, обновлению vCenter и ESXi, GPU профили (в 8.0 Update 3) — включая поддержку разных vGPU, GPU Media Engine, dual DPU и live patch FSR.
• vSphere 9 / VMware Cloud Foundation 9.0: новый подход к управлению жизненным циклом – поддержка live patch для vmkernel, NSX компонентов, более мощные «монстр-ВМ» (до 960 vCPU), direct upgrade с 8-й версии, image-based lifecycle management.

Работа с памятью

• vSphere 8: рекомендации для Optane PMem, vPMEM/vPMEMDisk, управление памятью через ESXi.
• vSphere 9 (через Cloud Foundation 9.0): внедрён memory tiering, позволяющий увеличить плотность ВМ в 2 раза при минимальной потере производительности (5%) и снижении TCO до 40%, без изменений в гостевой ОС.

Документ vSphere 9.0 Performance Best Practices содержит обновлённые и расширенные рекомендации для платформы vSphere 9, уделяющие внимание аппаратному уровню (BIOS-настройки, безопасность), инфраструктурному управлению, а также новым подходам к памяти (главный из них - memory tiering).

PowerCLI уже давно зарекомендовал себя как надежный и широко используемый инструмент автоматизации в средах VMware. Он остаётся одним из наиболее предпочитаемых инструментов среди клиентов, и его популярность подтверждается цифрами — по оценкам, ежегодно происходит от 1,5 до 2 миллионов загрузок. Для тех, кто интересуется, эти данные можно проверить, посмотрев некоторые статистические показатели на PowerShell Gallery.

Растянутые кластеры vSAN Stretched Clusters — это чрезвычайно популярная топология, используемая большим процентом клиентов VMware. Они зарекомендовали себя как простой и надежный способ достижения устойчивости на уровне площадки без той сложности, которая присуща метрокластерам на базе систем хранения. В версии VCF 9.0 vSAN представляет новые функции, которые повышают гибкость, доступность и упрощают операционные задачи для растянутых кластеров.

• Во-первых, теперь поддерживаются растянутые вычислительные кластеры, которые могут монтировать хранилище растянутого кластера vSAN, что упрощает использование растянутых кластеров в среде vSphere.
• Во-вторых, новая функция обслуживания на уровне площадки расширяет понятие "режим обслуживания" до уровня всей площадки в растянутом кластере.
• И, в-третьих, функция ручного захвата управления площадкой предоставляет администратору возможность самостоятельно восстановить одну площадку в случае серьезного двойного отказа площадок в растянутом кластере.

Лучший способ растянуть кластеры vSphere между площадками

vSAN 8 Update 2 поддерживал кластеры хранения vSAN в топологии растянутого кластера, но имел определённые ограничения. Единственным типом клиентского кластера, который мог монтировать целевое хранилище, был также растянутый кластер vSAN. Любой кластер vSphere, которому требовалось монтировать хранилище, мог располагаться только на одной из двух площадок. Это означало, что для обычных кластеров vSphere можно было обеспечить устойчивость данных между двумя площадками, но нельзя было обеспечить устойчивость и высокую доступность рабочих нагрузок виртуальных машин на обеих площадках одновременно. Причина такого ограничения заключалась в том, что хосты, входящие в кластер vSphere, не имели представления о доменах отказа, как это реализовано в растянутом кластере vSAN.

vSAN в VCF 9.0 устраняет этот пробел и позволяет использовать кластер хранения vSAN, растянутый между двумя площадками, с кластером vSphere. В топологии растянутого кластера это означает, что кластер хранения vSAN может быть растянут между двумя площадками (как и ранее), и один или несколько кластеров vSphere, также растянутых между этими двумя географическими площадками, могут монтировать это хранилище (что ранее не поддерживалось). Это фактически создаёт гораздо более простой аналог «метрокластера хранения», устраняя сложность традиционных метрокластеров на базе систем хранения за счёт простой и надёжной архитектуры vSAN.

Упрощённое обслуживание площадки для растянутых кластеров vSAN

Ранее в vSAN переход в режим обслуживания происходил на уровне отдельного хоста. Для клиентов, использующих vSAN в среде растянутого кластера, не существовало простого или автоматизированного способа перевести в режим обслуживания все хосты, составляющие одну площадку. Задача обслуживания на «уровне площадки» была одной из самых частых просьб со стороны клиентов. Хотя ранее это можно было выполнить вручную, процесс включал в себя множество шагов, был подвержен ошибкам и, в зависимости от условий, мог не обеспечить требуемую согласованность данных.

В VCF 9.0 обслуживание площадки в растянутом кластере vSAN стало значительно проще.

Теперь действия, необходимые от администратора, сводятся практически к одному клику в пользовательском интерфейсе или вызову API. Этот процесс обеспечивает безопасный перевод всех хостов одной площадки в режим обслуживания при сохранении согласованности данных. Новый рабочий процесс предлагает не только надёжный способ перевода всей площадки в режим обслуживания, но и простой механизм возврата из него.

Самостоятельное восстановление при длительном отказе двух площадок

Растянутый кластер vSAN позволяет выдержать отказ любой из трёх площадок, при этом данные остаются доступными. Ранее, при одновременном отказе основной площадки с данными и площадки-свидетеля, кластер vSAN блокировал доступ к данным из-за механизма кворума. Система кворума обеспечивает согласованность данных, предотвращая сценарии разделения кластера (split-brain). В случае длительного одновременного отказа основной площадки и площадки-свидетеля, данные на оставшейся площадке становились недоступными. Чтобы восстановить доступ к этим данным, требовалось обращаться в службу поддержки (GS), и процесс восстановления вручную был трудоёмким и подверженным ошибкам.

Функция ручного захвата управления площадкой (manual site takeover) в vSAN для VCF 9.0 предоставляет возможность самостоятельного восстановления в ситуации, когда одна из площадок находится в режиме обслуживания, а затем происходит одновременный отказ двух других площадок. В этом случае площадку, находящуюся в обслуживании, можно вернуть в рабочее состояние, запустить виртуальные машины и предоставить им доступ к хранилищу.

Изначально эта функция будет доступна в ограниченном виде через программу Broadcom “Technical Qualification Request” (TQR), которая пришла на смену процессу “Request for Product Qualification” (RPQ) от VMware для функциональности, ещё не выпущенной в общем доступе. Для подачи TQR, пожалуйста, свяжитесь с вашим поставщиком, чтобы обратиться в отдел управления продуктом vSAN.

Растянутые кластеры vSAN — это мощное решение для сред, где требуется максимальная устойчивость данных и максимальное время доступности виртуальных машин. Упрощение задач обслуживания и улучшение сценариев восстановления значительно усиливают самый простой способ развертывания VMware Cloud Foundation в мультисайтовой конфигурации.

VMware vSphere 7 достигнет конца основного срока поддержки (End of General Support) 2 октября 2025 года. Если вы в настоящее время используете vSphere 7, вам необходимо перейти на vSphere 8, чтобы продолжать получать поддержку продукта, обновления безопасности и патчи. Это также подготовит вас к переходу на VCF 9, когда вы будете к этому готовы.

Существует два варианта обновления:

1. Вы можете напрямую обновить vSphere 7 до vSphere 8

2. Либо можно импортировать vSphere 7 в VMware Cloud Foundation (VCF) версии 5.2 и выполнить обновление домена рабочих нагрузок до версии 8 через VMware SDDC Manager.

Выбор подходящего пути зависит от ряда факторов, таких как готовность бизнеса, поддержка сторонних продуктов и конфигурация среды. Ниже описано, как команда VCF Professional Services подходит к каждому из этих вариантов.

Вариант 1: Обновление с использованием vSphere Lifecycle Manager

Этот вариант представляет собой традиционный способ обновления vSphere. Вы можете использовать vSphere Lifecycle Manager Images или vSphere Lifecycle Manager Baselines для выполнения задачи обновления.

Преимущества этого подхода:

• Используются уже существующие операционные процессы обновления.
• В большинстве случаев требуется минимальное изменение текущей среды.
• Нет необходимости в дополнительных виртуальных модулях (appliances).

Недостатки этого подхода:

• Вам необходимо вручную выполнять проверки совместимости и валидации между компонентами, что может занять много времени.
• Каждая среда проектируется отдельно, что может привести к задержкам из-за различных архитектурных решений между экземплярами VMware vCenter.

Шаги по обновлению с использованием vSphere Lifecycle Manager

Многие организации сначала выполняют обновление на тестовой (staging) среде перед тем, как переходить к рабочей (production). Шаги, как правило, одинаковы для любых сред.

Шаг 1: Планирование, предварительная проверка и подготовка среды к обновлению.

На этом этапе необходимо вручную подтвердить, что ваша среда поддерживает новые версии. Начните с изучения Release Notes для vSphere 8 и проверьте, поддерживают ли ваши интеграции с другими продуктами VMware или сторонними приложениями vSphere 8. Также потребуется подготовка к обновлению vCenter и понимание изменений, связанных с обновлением хостов VMware ESX.

Шаг 2: Загрузка бинарных файлов (если необходимо).

После планирования нужно загрузить необходимые бинарные файлы. Это можно сделать на сайте поддержки Broadcom.

Шаг 3: Обновление vCenter.

Обновление vCenter можно выполнить несколькими способами, в зависимости от требований пользователя. Существует три основных метода:

• Обновление с сокращённым временем простоя (Reduced Downtime Upgrade) - при этом способе разворачивается вторичный виртуальный модуль, и конфигурационные данные переносятся на него. Это наиболее предпочтительный метод, поскольку он обеспечивает минимальные простои по сравнению с другими способами обновления.

• Установщик vCenter (vCenter Installer) – установщик vCenter включает опцию обновления, которая позволяет обновить существующий виртуальный модуль. Этот метод может быть использован в случае, если недостаточно ресурсов для развертывания второго модуля.

• Обновление через интерфейс управления виртуальным модулем (Virtual Appliance Management Interface Upgrade) – этот метод позволяет автоматически загрузить и установить бинарные файлы напрямую из интерфейса управления виртуальным модулем vCenter. Мы также можем использовать этот способ, если недостаточно ресурсов для развертывания второго модуля.

Шаг 4: Обновление хостов ESX.

После обновления vCenter можно переходить к обновлению хостов ESX. Существует несколько способов обновления хостов ESX. VMware использует два основных подхода:

• vSphere Lifecycle Manager - это предпочтительный метод, так как он позволяет обновлять целые кластеры одновременно, вместо обновления каждого хоста по отдельности. Это самый простой способ выполнения обновлений.

• Сценарные обновления (Scripted Upgrades) – этот метод рекомендуется, когда необходимо обновить большое количество хостов. Существует несколько способов автоматизации обновления с помощью сценариев, что позволяет адаптировать процесс под конкретные операционные процедуры и используемые языки скриптов.

Шаг 5: Обновление VMware vSAN.

После обновления хостов следующим шагом является обновление формата дисков vSAN. Этот шаг рекомендуется, но не является обязательным. Обновление vSAN позволяет воспользоваться новыми функциями.

Шаг 6: Обновление версии vSphere Distributed Switch.

Версию vSphere Distributed Switch также можно обновить. Этот шаг также является необязательным, однако рекомендуется его выполнить, чтобы получить доступ к новым возможностям.

Шаг 7: Проверка после обновления (Post-Upgrade Validation).

Этот шаг зависит от конкретной среды и может включать дополнительные обновления других компонентов для поддержки новой версии. Кроме того, вам потребуется ввести новые лицензии и выполнить все необходимые проверки.

На этом процесс обновления среды vSphere с использованием vSphere Lifecycle Manager завершается.

Вариант 2: Импорт vSphere в экземпляр VCF и обновление через SDDC Manager

Второй вариант — это импорт среды vSphere в VCF 5.2 с последующим обновлением через консоль SDDC Manager. Для этого у вас уже должен быть развернут экземпляр VCF.

Преимущества импорта vSphere в VCF и обновления через SDDC Manager:

• VCF включает в себя мощный механизм проверки предварительных условий, что упрощает процесс обновления.
• При импорте vSphere в VCF ваша среда проверяется, и определяются необходимые исправления, чтобы привести её в соответствие со стандартной архитектурой VCF.
• Вы можете воспользоваться другими возможностями VCF, такими как встроенное управление сертификатами и паролями. Эти функции ускоряют процесс обновления, позволяя легко изменять пароли и сертификаты.

Недостатки:

• Требуются дополнительные виртуальные модули. VCF представляет собой полноценный программно-определяемый датацентр, и такие компоненты, как VMware NSX, являются обязательными. Это требует выделения дополнительных ресурсов.
• Как упомянуто в разделе с преимуществами, приведение среды к стандарту VCF может потребовать выполнения определённых исправлений.

Шаги по импорту vSphere в VCF и обновлению через SDDC Manager

Шаг 1: Импорт существующей среды vSphere в конфигурацию VCF.

Используйте VCF Import Tool для проверки предварительных условий и выполнения импорта в уже существующий экземпляр VCF.

Шаг 2: Обновление vSphere через SDDC Manager.

После того как в среде доступен SDDC Manager, вы можете использовать его для выполнения следующих задач:

• Загрузка пакетов обновлений (Download Update Bundles) – скачайте необходимые пакеты, чтобы иметь возможность выполнить обновление.

• Выполнение предварительных проверок (prechecks) – выполните проверку предварительных условий, чтобы выявить проблемы, которые могут привести к сбою обновления. Если будут обнаружены какие-либо ошибки или проблемы, их необходимо устранить перед продолжением процесса.

• Обновление компонентов (Upgrade Components) – обновите все компоненты vSphere (vCenter и ESX). SDDC Manager выполнит обновление в правильной последовательности, чтобы обеспечить совместимость с перечнем компонентов (Bill of Materials) VCF 5.2.

Шаг 3: Проверка после обновления (Post-Upgrade Validation).

Этот шаг зависит от конкретной среды и может потребовать дополнительных обновлений других компонентов для поддержки новой версии. Кроме того, потребуется ввести новые лицензии и выполнить все необходимые проверки.

Как уже упоминалось, данный вариант требует наличия развернутого экземпляра VCF. Если его нет, вы можете сначала обновить хотя бы один экземпляр vCenter 7 до vSphere 8, используя Вариант 1, а затем преобразовать этот экземпляр vSphere в VCF.

Оптимальная ИТ-инфраструктура характеризуется способностью поддерживать растущее количество рабочих нагрузок со временем и управлять изменениями потребностей в ресурсах в режиме реального времени при сохранении максимальной производительности. VMware Cloud Foundation упрощает внедрение облачной операционной модели в большом масштабе, тем самым повышая гибкость ИТ, расширяя масштабируемость инфраструктуры, улучшая безопасность и снижая совокупную стоимость владения.

Современная инфраструктура требует эффективного уровня управления и эксплуатации, который охватывает полный контроль жизненного цикла компонентов, обеспечивает прозрачность затрат и предоставляет четкий обзор общей безопасности системы.

Ключевым компонентом стека VCF является решение VMware Cloud Foundation Operations, которое помогает организациям создавать, эксплуатировать и защищать инфраструктуру частного облака за счёт развертывания и поддержки компонентов на уровне всего парка, обеспечения единой видимости и повышенной производительности на всех уровнях — от рабочих нагрузок до инфраструктуры, а также соблюдения нормативных и внутренних требований. Среди преимуществ — более быстрое достижение бизнес-результатов, улучшенное использование ресурсов, сокращение времени на устранение неполадок, предсказуемость затрат и безопасная, соответствующая требованиям среда. В рамках релиза VCF 9.0 ключевыми новыми и усовершенствованными возможностями VCF Operations являются:

• Построение стека VCF
• Управление парком ресурсов
• Интегрированные операции
• Управление затратами
• Усиленная безопасность

Построение стека VCF

VMware Cloud Foundation 9.0 изменяет подход к развертыванию и построению инфраструктуры частного облака. Установщик VCF (VCF Installer) позволяет клиентам с лёгкостью создавать повторяемые участки инфраструктуры VCF, такие как кластеры приложений, для масштабирования парка ресурсов с целью повышения операционной эффективности и согласованности компонентов.

Парк VCF (VCF fleet) — это новый термин в VCF 9.0, обозначающий всю инфраструктуру, включая VCF Operations, VCF Automation, vCenter, NSX Manager, кластер vSphere, домены рабочих нагрузок и другие компоненты внутри VCF. Можно развернуть несколько экземпляров VCF, однако модули VCF Operations и VCF Automation существуют только в единственном экземпляре.

VCF 9.0 представляет новый мастер установки (Install wizard), который пошагово и интуитивно ведёт пользователя через процесс создания инфраструктуры. Можно развернуть новый парк ресурсов (fleet) или добавить инфраструктуру к уже существующей VCF-среде. Поддерживается настройка размера инфраструктуры и высокая доступность, а также возможность масштабирования частного облака с помощью JSON-файлов. Этот JSON можно сохранить для будущих развертываний и использовать в качестве шаблона. Перед установкой доступен предварительный просмотр и проверка параметров. После завершения работы установщика пользователь может войти в VCF Operations и приступить к работе.

Управление парком ресурсов (Fleet Management)

Предприятия, стремящиеся к масштабированию, нуждаются в согласованности своей инфраструктуры. Управление парком в VCF Operations помогает создавать, управлять и масштабировать инфраструктуру частного облака, обеспечивая единообразие всех компонентов. Оно объединяет доступ к ключевым административным задачам для инфраструктурных и управляющих компонентов. Некоторые из ключевых возможностей управления парком включают:

1. Управление лицензиями

VCF Operations теперь выступает в роли менеджера лицензий для всего стека VCF. С помощью VCF Operations лицензирование становится проще, оно унифицировано за счёт использования одного лицензионного файла. Ранее использовались длинные 25-символьные шестнадцатеричные ключи, которые нужно было вводить для каждого компонента отдельно. Теперь для каждого экземпляра VCF Operations используется один лицензионный файл, что облегчает распределение лицензий, отслеживание их использования и внесение изменений по ядрам и объёму хранилища vSAN (в TiB). Расширенные сервисы, такие как VMware Private AI Foundation с NVIDIA и дополнительное хранилище vSAN, также учитываются в этом файле. Другие дополнения по-прежнему используют традиционные лицензионные ключи.

2. Единый вход и централизованное управление идентификацией

VCF Operations обеспечивает поддержку единого входа (SSO) для VCF и всех экземпляров vCenter в парке. VCF 9.0 упрощает и модернизирует механизм SSO, предоставляя простое управление источниками идентификации, что снижает операционную сложность и повышает контроль над доступом благодаря гибкой настройке. Также возможно применять настройки клиента SSO из VCF Operations к отдельным компонентам. Система поддерживает различные решения идентификации, включая Active Directory Federation Services, Azure AD, OKTA, Ping и OAuth 2.0.

3. Управление сертификатами и паролями

VCF 9.0 внедряет централизованное управление сертификатами в VCF Operations, обеспечивая упрощённый пользовательский опыт во всей среде VCF. Эта функция позволяет выполнять обновления сертификатов без сбоев, автоматически продлевать их с помощью нескольких удостоверяющих центров (CA), а также импортировать внешне подписанные сертификаты. В результате упрощается администрирование, усиливаются меры безопасности и повышается соответствие требованиям.

Централизованная панель управления обеспечивает упрощённое управление паролями за счёт интеграции и консолидации. Система предоставляет полный обзор состояния паролей и функций управления, включая обновление, ротацию и уведомления об истечении срока действия.

4. Управление жизненным циклом

VCF 9.0 улучшает управление жизненным циклом, объединяя задачи второго дня (Day 2) в едином интерфейсе VCF Operations. Это упрощает контроль версий и оркестрацию обновлений, а также оптимизирует процессы для сокращения количества перезагрузок хостов и поддержки автоматизированных обновлений сразу в нескольких кластерах.

Интегрированные операции

Мониторинг работы всей среды может быть затруднён по многим причинам: отсутствие согласованности при анализе инфраструктурных данных (диагностика, журналы, метрики, сетевые потоки), усталость от множества оповещений, необходимость отслеживания сторонних решений и контейнеров, а также ограниченная гибкость при перемещении рабочих нагрузок в рамках виртуальной среды. Последний релиз VCF Operations решает эти проблемы, объединив ряд функций, ранее распределённых между разными продуктами.

1. VCF - здоровье и диагностика

Diagnostic Findings (диагностические выводы) — единое представление для отслеживания корреляции проблем во всей инфраструктуре за счёт сканирования и анализа известных сигнатур, с отображением текущих проблем на странице Active Findings.

VCF Health (мониторинг состояния) — даёт представление о текущем состоянии всех экземпляров vCenter, включая данные о подключениях, использовании ресурсов и сервисах, а также содержит функции общего назначения, такие как:

• Операции с виртуальными машинами
• vMotion
• Управление снапшотами
• Мониторинг состояния vSAN

2. Операции с хранилищем

Понимание использования хранилища имеет ключевое значение, и VCF Operations предоставляет мощные средства для анализа тенденций потребления ресурсов. В последнем релизе VCF Operations предлагает единое окно управления всеми аспектами хранения данных, включая инвентаризацию, конфигурацию и производительность в рамках VCF.

Инструмент Storage Distribution Insights отображает, как хранилище распределено между кластерами и рабочими нагрузками. Такой подробный обзор позволяет эффективно управлять ресурсами и быстро устранять проблемы, обеспечивая оптимальную производительность и использование хранилища.

3. Сетевые операции

VCF Operations теперь включает в себя интегрированные сетевые операции, обеспечивая полный обзор сети с возможностью мониторинга её состояния, анализа трафика и получения информации о приложениях. Система может автоматически обнаруживать бизнес-приложения и их уровни, чтобы настроить их отслеживание и начать мониторинг.

4. Интегрированные журналы

VCF Operations объединяет анализ файлов журналов всех компонентов, упрощая фильтрацию событий, визуализацию тенденций и ускоряя устранение неполадок из единой консоли. Оповещения на основе логов и настраиваемые панели мониторинга позволяют администраторам отслеживать динамику событий, выявлять аномалии и быстро диагностировать проблемы.

Функция Log Assist облегчает поиск и консолидацию журналов для эффективного проведения анализа первопричин (Root Cause Analysis, RCA) и ускоренного устранения неисправностей. В последнем релизе пользователи могут создавать архивные пакеты журналов и прикреплять их к обращениям в службу поддержки для более оперативного взаимодействия с техническими специалистами.

5. Расширяемость с использованием встроенного конструктора пакетов (Management Pack Builder)

В VCF Operations теперь доступен Management Pack Builder — встроенный конструктор пакетов управления, который предоставляет панели мониторинга, оповещения и метрики для всестороннего наблюдения и управления как компонентами VCF, так и сторонними устройствами.

6. Мониторинг Supervisor-кластера и Kubernetes-сервиса vSphere

VCF Operations теперь нативно поддерживает мониторинг Supervisor-кластера и VMware Kubernetes Service (VKS). С помощью агента Telegraf данные об инвентаризации и метриках передаются из Supervisor и VKS в VCF Operations.

Предоставляются готовые дэшборды и ключевые показатели производительности (KPI) для Supervisor-кластера, включая загрузку CPU, использование памяти, дисков, состояние узлов, подов и метрики на уровне контейнеров — всё это помогает в диагностике проблем с производительностью, связанными с Supervisor.

7. Планирование миграции рабочих нагрузок

Планирование миграции в VCF предлагает комплексный подход к масштабному переносу рабочих нагрузок, объединяя мощные возможности VCF Operations for Networks и VCF Operations HCX.

В этом релизе представлены основные функции этой возможности:

• Пользователи могут легко и эффективно определить область миграции на основе приложений и выявить зависимости, чтобы не упустить важные компоненты. Обнаружение зависимостей приложений и сетей снижает риск ошибок при миграции и повышает надёжность.
• Миграционные волны позволяют разбить процесс переноса на управляемые этапы. Это помогает сосредоточиться на небольших группах ресурсов, лучше планировать и выполнять миграцию поэтапно, снижая риски и сложность.
• Информация об использовании памяти, ядер и хранилища помогает учитывать ограничения ресурсов и принимать обоснованные решения для их оптимального распределения в процессе миграции.

По мере развития функции планирования миграции пользователи получат более плавный и эффективный процесс переноса с чётким пониманием потребностей в ресурсах и зависимостях, что обеспечит более продуманный и управляемый подход к миграции рабочих нагрузок как внутри VCF, так и между VCF-средами.

Управление затратами

VCF Operations помогает оценить отдачу от инвестиций в VCF. Он отслеживает общую стоимость владения всей инфраструктурой, потенциальную и фактическую экономию благодаря рекомендациям, позволяя оценить эффективность и снижение затрат со временем.

Функции управления затратами в VCF Operations позволяют с высокой точностью отслеживать инфраструктурные расходы, затраты на лицензии и сопутствующие сервисы. Также поддерживаются механизмы showback и chargeback, позволяющие командам приложений понимать и контролировать стоимость используемой ими инфраструктуры.

ИТ-администраторы и провайдеры могут использовать:

• Cost Drivers — распределение затрат по категориям
• Pricing Policies — создание тарифных планов
• Showback — отображение затрат по фактическому использованию
• Chargeback — выставление счетов на основе заданных моделей ценообразования

1. Тарифные планы (Rate Cards)

Для точного выставления счетов арендаторам провайдеры могут создавать тарифные планы (rate cards), определяя стоимость единицы потребления ресурсов. Это позволяет единообразно рассчитывать затраты в соответствии с заданными условиями.

Тарифные планы можно настраивать по различным параметрам: вычислительные ресурсы (CPU и память), хранилище, сеть, гостевые ОС, теги, фиксированные единовременные расходы, корректирующие коэффициенты. Такая гибкость позволяет адаптировать цены как к техническому потреблению, так и к бизнес-модели.

Планы совместимы с последними лицензиями VCF и позволяют точно учитывать затраты по ядрам CPU и объёму хранилища.

2. Перерасчёт затрат (Chargeback)

Провайдеры могут получать детализированные данные о перерасчёте затрат с помощью улучшенных панелей, которые отображают расходы с разных управленческих уровней:

• Обзор (Overview): сводная информация по затратам и ценам по организациям, регионам и запущенным ВМ.
• Организации (Organizations): распределение затрат по организациям и региональным квотам.
• Проекты (Projects): полное представление затрат и цен по проектам в VCF Automation с детализацией по пространствам имён и развёртываниям.

VCF Operations теперь поддерживает современные модели перерасчёта для IaaS как для провайдеров, так и для корпоративных команд приложений. Возможности перерасчёта интегрированы с новыми подходами к развёртыванию, реализуемыми через VCF Automation.

3. Анализ затрат (Cost Analysis)

Функции анализа затрат позволяют организациям получить чёткое представление о расходах на частное облако, выявить неэффективности и принимать обоснованные решения для оптимизации инвестиций.

Теперь пользователи могут быстро сравнивать метрики, например, стоимость эксплуатации и цену оказания услуг, в упрощённом интерфейсе. Это ускоряет получение аналитики, помогает оперативно выявлять наиболее затратные зоны и возможности для оптимизации всего за несколько кликов.

Усиленная безопасность

Возможности управления безопасностью обеспечивают комплексный обзор как инфраструктурного, так и пользовательского уровня, что снижает общую сложность с точки зрения рисков и поддерживает высокий уровень безопасности предприятия.

1. Дэшборды SecOps

Панель управления безопасностью (Security Operations Dashboard) предоставляет детализированный, real-time обзор аутентификации пользователей, прав доступа и состояния инфраструктуры, помогая проактивно управлять безопасностью во всех развертываниях VCF.

Инструмент охватывает ключевые аспекты защиты инфраструктуры, включая:

• Шифрование хостов
• Соответствие режимов работы хостов
• Шифрование кластеров vSAN
• Предупреждения о нарушениях CVE
• Состояние сертификатов
• Статус шифрования виртуальных машин

2. Отчётность по соответствию требованиям (Compliance Reporting)

VCF Operations предоставляет оповещения, политики и отчёты для проверки соответствия ресурсов VCF установленным стандартам, обеспечивая непрерывный контроль над соответствием, оперативные уведомления и поддержание общей политики безопасности инфраструктуры, снижая организационные и бизнес-риски.

В качестве бенчмарков могут использоваться следующие типы стандартов:

• Предопределённые эталоны VMware, отслеживающие состояние среды в соответствии с рекомендациями по безопасности от VMware
• Пользовательские политики, созданные вручную, для проверки среды на соответствие внутренним требованиям
• Готовые комплекты нормативных стандартов, включая:
  • CIS
  • DISA STIG
  • FISMA
  • HIPAA
  • ISO
  • PCI DSS

Организации могут проактивно выявлять нарушения конфигурации и отклонения от соответствия требованиям, используя выбранные эталоны. Кроме того, благодаря интеграции VCF с инструментами управления конфигурациями от VMware или сторонних разработчиков возможна автоматическая коррекция нарушений соответствия.

В версии VCF 9.0 были добавлены новые комплекты соответствия для:

• CIS (vSphere 8.0)
• NIST SP 800-171
• NIST SP 800-53 R5

А также обновлены средства проверки для:

• HIPAA
• PCI DSS v4.0
• ISO/IEC 27001:2022

Мы видим, как VCF Operations помогает клиентам модернизировать инфраструктуру. Он предоставляет функции, которые позволяют инфраструктуре VCF работать как единая автоматизированная система, помогая организациям достигать своих ИТ- и бизнес-целей.

Дополнительные материалы

• Release notes - подробная информация о новых возможностях
• Тестовая лаборатория: попробуйте VCF 9.0 в действии в новых лабах Hands-on Lab — What’s New in VMware Cloud Foundation 9.0 – Operations. Оцените возможности мониторинга, диагностики, анализа сетевых потоков, расширенного управления хранилищем, безопасности и прозрачности затрат.

Узнать больше:

• Веб-страница: VMware Cloud Foundation Operations
• Документация: VCF Documentation

VMware представила унифицированный фреймворк разработки VCF SDK 9.0 для Python и Java.

Улучшение опыта разработчиков (Developer Experience) — один из главных приоритетов в дальнейшем развитии платформы VMware Cloud Foundation (VCF). Если рассматривать автоматизацию в целом, то можно выделить две чёткие категории пользователей: администраторы и разработчики.

Администраторы в основном сосредоточены на операционной автоматизации, включая развертывание, конфигурацию и управление жизненным циклом среды VCF. Их потребности в автоматизации обычно реализуются через написание скриптов и рабочих процессов, которые управляют инфраструктурой в масштабах всей организации.

Разработчики, напротив, ориентированы на интеграцию возможностей VCF в пользовательские приложения и решения. Им необходимы API и SDK, обеспечивающие программный доступ к сервисам и данным VCF, позволяя разрабатывать собственные инструменты, сервисы и расширения. Потребности в автоматизации у этих двух групп значительно различаются и соответствуют их уникальным ролям в экосистеме VCF. Понимая эти различия, Broadcom предлагает набор интерфейсов прикладного программирования (API), средств разработки (SDK) и разнообразных инструментов автоматизации, таких как PowerCLI, Terraform и Ansible.

Оглядываясь назад, можно сказать, что VMware хорошо обслуживала сообщество администраторов, предоставляя им различные инструменты. Однако API и SDK требовали улучшения в области документации, лучшей интеграции с VCF-стеком в целом и упрощения процесса для разработчиков. До выхода VCF 9.0 разработчики использовали отдельные SDK решений, сталкиваясь с трудностями, связанными с их интеграцией — такими как совместимость, аутентификация и сложность API. С выходом VCF 9.0 VMware рада объявить о доступности Unified VCF SDK 9.0. Давайте подробнее рассмотрим, что это такое.

Unified VCF SDK

Unified VCF SDK доступен с привязками к двум языкам — Java и Python. Это объединённый SDK, который включает в себя все основные SDK решений VCF в единый, упрощённый пакет. В своей первой версии Unified VCF SDK объединяет существующие SDK и добавляет новые библиотеки для установщика VCF и менеджера SDDC.

Список компонентов VCF, включённых в первую версию Unified VCF SDK:

• VMware vSphere
• VMware vSAN
• VMware Cloud Foundation SDDC Manager (новый)
• VMware Cloud Foundation Installer (новый)
• VMware vSAN Data Protection

Несмотря на то, что Unified VCF SDK поставляется как единый пакет, пользователи могут устанавливать и использовать только те библиотеки, которые необходимы для конкретных задач.

Для краткости в этом тексте Unified VCF SDK будет обозначаться как VCF SDK.

Преимущества

VCF SDK обеспечивает простой, расширяемый и единообразный опыт для разработчиков на протяжении всего жизненного цикла разработки.

Упрощённый жизненный цикл разработчика

С этим релизом были стандартизированы методы доставки и распространения, чтобы поддерживать различные сценарии развертывания:

• Онлайн-установка через PyPI (Python) и Maven (Java) — для прямого доступа и лёгкой установки/обновлений.
• Офлайн-установка через портал разработчиков Broadcom — идеально для сред с ограниченным доступом в интернет.
• Готовность к CI/CD — интеграции через пакеты и инструкции, размещённые на GitHub, для бесшовного включения в автоматизированные пайплайны при установке и обновлении.

Улучшенная документация и онбординг

VMware переработала документацию, чтобы упростить старт:

• Руководства по началу работы для Python и Java.
• Примеры кода для быстрого освоения.

OpenAPI-спецификация

OpenAPI-спецификация описывает API в стандартизированном машинно-читаемом формате (YAML/JSON). С выходом VCF SDK были также публикованы OpenAPI-спецификации для API-эндпоинтов. Это не просто документация — это шаг к философии API-first и ориентированности на разработчиков.

С помощью OpenAPI-спецификаций разработчики могут:

• Автоматически генерировать клиентские библиотеки на предпочитаемых языках с помощью инструментов вроде Swagger Codegen, Kiota или OpenAPI Generator.
• Загружать спецификации в такие инструменты, как Swagger UI, Redoc или Postman, чтобы визуально исследовать доступные эндпоинты, параметры, схемы ответов и сообщения об ошибках.
• Понимать структуру API и его поведение.

Скачать OpenAPI-спецификацию можно с портала разработчиков Broadcom или из репозитория GitHub.

VCF Python SDK

VCF Python SDK включает в себя следующие модули:

Каналы распространения

Unified VCF SDK доступен через различные каналы распространения. Это сделано для того, чтобы удовлетворить потребности разных типов сред и разработчиков — каждый может получить доступ к SDK в наиболее удобном для него месте. Ниже перечислены доступные каналы, откуда можно загрузить VCF SDK.

Портал разработчиков Broadcom

VCF Python SDK доступен для загрузки на портале разработчиков Broadcom. Вы можете распаковать содержимое ZIP-архива vcf-python-sdk-9.0.0.0-24798170.zip, чтобы ознакомиться с библиотеками SDK, утилитами и примерами. Однако сторонние зависимости не входят в состав архива — они перечислены в файле requirements-third-party.txt, находящемся внутри vcf-python-sdk-9.0.0.0-24798170.zip.

Файлы .whl компонентов VCF SDK находятся в папках ../pypi/*, а примеры кода для компонентов расположены в директориях вида /<имя_компонента>-samples/.

PyPI

VCF SDK доступен в PyPI, что позволяет разработчикам устанавливать и обновлять модуль онлайн. Это самый быстрый способ начать работу с VCF SDK.

Чтобы установить VCF SDK, выполните следующую команду:

Пакеты, установленные через pip, можно автоматически обновлять. Чтобы обновить VCF SDK, используйте команду:

Чтобы установить конкретную библиотеку из состава VCF SDK, выполните:

Примеры:

$ pip install pyvmomi
$ pip install vcf-installer

GitHub

Разработчики также могут скачать пакет VCF SDK из репозитория VMware на GitHub.

VCF Java SDK

VCF Java SDK включает в себя следующие артефакты:

Каналы распространения

Аналогично Python SDK, JAVA SDK также доступен через различные каналы распространения, что позволяет использовать его в самых разных средах.

Портал разработчиков Broadcom

VCF Java SDK доступен для загрузки на портале разработчиков Broadcom. Вы можете распаковать содержимое ZIP-архива vcf-java-sdk-9.0.0.0-24798170.zip, чтобы ознакомиться с библиотеками SDK, утилитами и примерами.

Файлы привязок SDK .jar, утилит .jar, а также BOM-файлы находятся в папке:

Maven

Артефакты VCF SDK доступны в Maven Central под groupId: com.vmware.sdk. В таблице ниже указаны данные об артефактах VCF SDK для версии 9.0.0.0.

Чтобы начать работу с VCF SDK, добавьте зависимость в файл pom.xml вашего проекта:

<dependencies>
<dependency>
<groupId>com.vmware.sdk</groupId>
<artifactId>vcf-sdk</artifactId>
<version>9.0.0.0</version>
</dependency>
</dependencies>

GitHub

Разработчики также могут скачать пакет VCF SDK из репозитория VMware на GitHub.

Журнал изменений API

С выходом VCF 9.0 VMware начала публиковать журнал изменений API. В нём отражаются все изменения: новые API, обновления существующих и уведомления об устаревании. Ознакомиться с журналом изменений можно здесь.

Ресурсы

• Release Notes
• API Change Log
• Broadcom Developer Portal
• VCF Python SDK on PyPI 
• VCF Java SDK on Maven 

Репозитории Github:

• VCF Python SDK 
• VCF JAVA SDK
• VCF OpenAPI Specifications

Страницы Getting Started:

• Getting Started with VCF Python SDK
• Getting Started with VCF JAVA SDK 
• Getting Started with VCF OpenAPI Specification

Заключение

С выпуском VMware Cloud Foundation 9.0 объединение различных библиотек в один SDK с улучшенной документацией, примерами кода и спецификацией OpenAPI — это важный шаг к простому, расширяемому и согласованному опыту для разработчиков.

Следующий шаг за вами — попробуйте Unified VCF SDK 9.0 и поделитесь с нами своими отзывами.

В платформе VMware vSphere 9 в рамках инфраструктуры VMware Cloud Foundation (VCF) 9.0 была значительно расширена область компонентов ESX, которые можно обновлять с помощью технологии Live Patch. Теперь это включает в себя vmkernel, пользовательские демоны, компоненты NSX, а также уже ранее поддерживаемое выполнение виртуальных машин (vmx), которое было адаптировано к Live Patch.

Используйте Live Patch уже сегодня

Недавно выпущенное обновление ESX 9.0.0.0100 уже полноценно поддерживает Live Patch (см. Release Notes). Вы можете применить это обновление к кластерам ESX 9.0.0 (24755229) с помощью Live Patch, заодно и протестируете работу этой технологии.

Если коротко: Live Patch позволяет применять некоторые обновления ESX без прерывания работы, то есть без необходимости эвакуации виртуальных машин с хоста.

Это означает, что в будущем, вероятно, появится больше обновлений, которые можно будет устанавливать с помощью Live Patch — быстро и без простоев. В первую очередь Live Patch ориентирован на важные обновления безопасности, поскольку критически важно, чтобы организации внедряли их как можно быстрее. Однако не каждое обновление будет поддерживать Live Patch.

Напоминание: чтобы определить, поддерживает ли обновление Live Patch, проверьте Release Notes — в них будет указано, если такая возможность есть. Интерфейсы консолей VCF и vSphere Lifecycle Manager также будут отображать эту информацию:

При обновлении пользовательских демонов (user-space daemons) с помощью Live Patch может потребоваться перезапуск соответствующего демона. В зависимости от того, какой демон обновляется и перезапускается, ESX-хост может на короткое время потерять связь с vCenter. Например, обновление демона hostd может потребовать его перезапуска. Это может привести к кратковременному отображению хоста как отключённого от vCenter — это ожидаемое поведение и не влияет на работу виртуальных машин.

Если Live Patch затрагивает среду исполнения виртуальных машин (vmx), то в процессе обновления выполняется операция быстрой приостановки и возобновления (Fast Suspend-Resume, FSR) виртуальных машин. Не каждое обновление требует выполнения FSR. Подробнее об FSR можно прочитать вот тут. В vSphere с VCF 9.0 операция FSR выполняется значительно быстрее для виртуальных машин с включённым vGPU, что позволяет выполнять Live Patch на кластерах с такими ВМ без прерывания работы AI/ML-приложений.

Перед выполнением задачи Live Patch, vSphere Lifecycle Manager проводит предварительную проверку (precheck), чтобы убедиться, что на хостах достаточно доступных ресурсов. Если ресурсов недостаточно, может потребоваться снизить нагрузку на хосты перед тем, как приступить к обновлению.

Ограничения Live Patch, имевшиеся в vSphere 8, сохраняются и в VCF 9.0. Среди них:

• Отсутствие поддержки Live Patch на системах с включёнными устройствами TPM 2.0
• Использование DPU в составе vSphere Distributed Services Engine
• Невозможность совмещать параллельный апдейт (parallel remediation) с Live Patch.

Дополнительную информацию см. в документации vSphere: Configuring vSphere Lifecycle Manager for Live Patches.

Недавно компания VMware выпустила полезный документ "VMware Cloud Foundation 9.0 and VMware vSphere Foundation 9.0 Feature Comparison & Upgrade Paths", в котором приводится сравнении функциональности VMware Cloud Foundation и vSphere Foundation, а также рассказывается о существующих вариантах апгрейда.

Издания платформы: Cloud Foundation vs vSphere Foundation

VMware Cloud Foundation (VCF) 9.0

Полноценная IaaS-платформа, предоставляющая Enterprise-возможности:

• vSphere (ESX и vCenter), vSAN, NSX и HCX
• Автоматизация управления жизненным циклом с помощью SDDC Manager, операции Fleet Management и VCF Operations
• Aria Automation в рамках портала самообслуживания, Terraform, GitOps, blueprints
• Оперативный мониторинг, комплаенс, chargeback через Aria Operations Enterprise
• Kubernetes как сервис, включая Supervisor Services, ArgoCD, Data / AI Services
• Поддержка больших объемов хранения (до 1 TiB/core), глобальной дедупликации, растянутых кластеров, QoS, снапшотов и многого другого

VMware vSphere Foundation (VVF) 9.0

Базовая, но мощная платформа виртуализации:

• Включает vSphere Kubernetes Service, vSAN, vCenter Standard, VCF Operations (включая базовый мониторинг и жизненный цикл)
• Не включает NSX, HCX, Aria Automation или Aria Operations Enterprise
• Поддерживает основное управление платформой виртуализации и контейнерами, но не полноценную автоматизацию и изоляцию тенантов

Сравнение ключевых возможностей

Пути обновления (Upgrade Paths)

В документе VMware четко описывает возможности перехода с предыдущих продуктов:

• Старые версии: vSphere Enterprise Plus, vSphere Standard, vCloud Suite, Aria Suite и другие можно мигрировать либо в vSphere Foundation 9.0 (если нужны базовые функции), либо сразу в VCF 9.0 для полной автоматизации и сетевых возможностей.

• Лицензирование:

  • Подписка VCF 9 или VVF 9 включает лицензию версии 9.0, а также ключи для версий 8.x, которые можно использовать или понижать (downgrade) при необходимости.

  • Это означает гибкость в выборе развертывания и возможность отката к предыдущим версиям в пределах лицензии.

Последовательность обновления при переходе на VCF 9.0

Broadcom рекомендует следующую схему для обновления компонентов в среде с несколькими доменами нагрузки (workload domains):

1. Aria Suite Lifecycle (до версии 8.18 Patch 2)
2. VCF Operations и Fleet Management
3. VCF Automation, VCF Operations – Networks, Logs (новый лог-менеджмент вместо Aria Logs)
4. SDDC Manager
5. HCX, NSX, затем vCenter
6. Identity Broker / VIDB
7. Supervisor, vSAN Witness, хосты ESX
8. vSAN, файловый сервис, VMware Tools, Virtual Hardware.

Важно: компонент Aria Operations for Logs 8.x не обновляется напрямую — миграция исторических данных происходит через Day-N операции в новом VCF Operations Logs.

Что выбрать?

• vSphere Foundation 9.0 — если нужна стабильная виртуализация с контейнерами и vSAN, но без сложной сетевой и автоматизационной логики.

• Cloud Foundation 9.0 — если требуется:

  • Автоматическая настройка облака (IaaS) под клиентов
  • Полнофункциональные сети и безопасность
  • Глобальное управление через единую платформу
  • Поддержка Kubernetes, AI, Data services
  • Полная интеграция Operations / Automation

Выводы

• VMware предложила две SKU-конфигурации, одна — мощная, полностью автоматизированная платформа IaaS (VCF), другая — компактная и эффективная инфраструктурная база ( vSphere Foundation).
• Лицензирование и upgrade гибкие — подписка VCF/VVF 9 позволяет использовать версию 9.0 или откатиться на 8.x в рамках лицензии.
• Обновление требует чёткого порядка, особенно при переходе с существующих систем – важна последовательность компонентов, миграция логов и identity.
• Выбор зависит от ваших нужд: простота и контейнеризация или полный спектр управления частным облаком с IaaS, безопасностью и DevOps-интерфейсами.

В числе множества новых возможностей, представленных в VMware Cloud Foundation 9.0, функция многоуровневой памяти (Memory Tiering) стала одной из ключевых в составе VMware vSphere для VCF 9.0. Как и многие другие функции vSphere, Memory Tiering с использованием NVMe снижает совокупную стоимость владения, полностью интегрируется с ESX (да, гипервизор называется снова ESX), а также с VMware vCenter. Она поддерживает гибкие варианты развертывания, предоставляя клиентам множество опций при настройке.

Memory Tiering с NVMe была представлена в составе VCF 9.0, и важно подчеркнуть её ценность для компаний, стремящихся сократить расходы, особенно при закупке оборудования, так как стоимость оперативной памяти составляет значительную часть спецификации аппаратного обеспечения (Bill of Materials, BOM). Функция, позволяющая масштабировать память за счёт использования недорогого оборудования, может существенно повлиять на распределение ИТ-бюджета и приоритетность проектов.

Memory Tiering с NVMe можно настроить через привычный вам интерфейс vCenter UI, с помощью командной строки через ESXCLI, а также через скрипты в PowerCLI. Можно использовать любую из этих опций или их комбинацию для настройки многоуровневой памяти как на уровне хоста, так и на уровне кластера.

Аппаратное обеспечение имеет значение

Перед настройкой функции Memory Tiering крайне важно обратить внимание на рекомендуемое оборудование. И это не просто совет, а настоятельная рекомендация. Поскольку в роли памяти будут использоваться устройства NVMe, важно, чтобы они были не только надёжными, но и демонстрировали высокую производительность при интенсивной нагрузке. Аналогично тому, как вы определяли рекомендуемые устройства для vSAN, здесь также есть требования: NVMe-устройства должны соответствовать классу выносливости D (не менее 7300 TBW) и классу производительности F или выше (не менее 100 000 операций записи в секунду) для использования в составе многоуровневой памяти. VMware рекомендует воспользоваться руководством по совместимости с vSAN, чтобы убедиться, что выбранные устройства соответствуют этим требованиям.

Также важно отметить, что поддерживается множество форм-факторов. Так что если в вашем сервере нет свободных слотов для 2.5-дюймовых накопителей, но есть, например, свободный слот M.2, вы вполне можете использовать его для Memory Tiering.

Создание раздела на NVMe

После того как вы тщательно выбрали рекомендованные NVMe-устройства (кстати, их можно объединить в RAID-конфигурацию для обеспечения отказоустойчивости), следующим шагом будет создание раздела для NVMe-уровня памяти. Если на выбранном устройстве уже существуют какие-либо разделы, их необходимо удалить перед конфигурацией.

Максимальный размер раздела в текущей версии составляет 4 ТБ, однако вы можете использовать и более ёмкое устройство — это позволит «циклически использовать ячейки» и потенциально продлить срок службы NVMe-накопителя. Хотя размер раздела зависит от ёмкости устройства (до 4 ТБ), фактический объём NVMe, задействованный в качестве памяти, рассчитывается на основе объёма DRAM на хосте и заданного соотношения. По умолчанию в VCF 9.0 применяется соотношение DRAM:NVMe как 1:1 — это в четыре раза больше, чем в технологическом превью на vSphere 8.0 Update 3.

Например, если у вас есть хост с 1 ТБ DRAM и NVMe-устройство на 4 ТБ, то будет создан раздел размером 4 ТБ, но использоваться в рамках Memory Tiering будет только 1 ТБ — если, конечно, вы не измените соотношение. Это соотношение настраивается пользователем, однако стоит проявить осторожность: изменение параметра может негативно повлиять на производительность и сильно зависит от характера и активности рабочих нагрузок. Подробнее об этом — далее.

В текущей версии создание раздела выполняется через командную строку ESXCLI на хосте с помощью следующей команды:

Пример:

Конфигурация хоста или кластера

После создания раздела tierdevice остаётся последний шаг — настроить хост или кластер. Да, вы можете гибко подойти к конфигурации: настроить один, несколько хостов или весь кластер целиком. В идеале рекомендуется настраивать кластер гомогенно; однако стоит учитывать, что некоторые типы виртуальных машин пока не поддерживаются в режиме NVMe Memory Tiering. К ним относятся:

• ВМ с высокими требованиями к производительности и низкой задержке
• Защищённые ВМ (SEV, SGX, TDX),
• ВМ с непрерывной доступностью (FT)
• "Монстр-машины" (1 ТБ памяти, 128 vCPU)
• Вложенные ВМ (nested VMs).

Если в одном кластере у вас сочетаются такие ВМ с обычными рабочими нагрузками, которые могут использовать Memory Tiering, вы можете либо выделить отдельные хосты для «особых» ВМ, либо отключить Memory Tiering на уровне конкретных виртуальных машин.

Для включения Memory Tiering на хосте вы можете воспользоваться ESXCLI, PowerCLI или интерфейсом vCenter UI. В ESXCLI команда очень простая:

В vCenter UI это делается путём изменения параметра VMkernel.Boot.memoryTiering на значение TRUE. Обратите внимание на слово BOOT — для применения параметра хост необходимо перезагрузить. Также перед внесением изменений хост нужно перевести в режим обслуживания.

А если вы хотите настроить весь кластер? Что ж, это даже проще. Вы можете воспользоваться функцией Desired State Configuration в vCenter. Всё, что нужно — создать новый черновик с включённой настройкой memory_tiering в разделе vmkernel > options, установив её в значение true. После этого остаётся просто применить этот драфт ко всем хостам в кластере (или только к выбранным хостам).

После применения конфигурации хосты автоматически будут переведены в режим обслуживания и перезагружены поочерёдно, по мере необходимости. И всё — на этом настройка завершена. Теперь вы можете воспользоваться преимуществами:

• Лучшего коэффициента консолидации ВМ
• Сниженной совокупной стоимости владения
• Простой масштабируемости памяти — по значительно более низкой цене

После завершения настройки вы увидите как минимум двукратное увеличение доступной памяти, а также визуальное отображение уровней памяти (memory tiers) в интерфейсе vCenter UI.

До начала VMware Explore 2025 остаётся совсем немного времени, и теперь участникам доступен один из самых ожидаемых инструментов подготовки — официальный каталог контента (Explore 2025 Content Catalog). Это ваш ключ к максимально продуктивному участию в главной конференции VMware.

Каталог включает более 350 сессий, практикумов, воркшопов и технических демонстраций, охватывающих весь стек решений VMware и ключевые технологические тренды. Среди них:

• Стратегии мультиоблачной инфраструктуры
• VMware Cloud Foundation (VCF) и интеграция с Broadcom
• Kubernetes, Tanzu и DevOps-подходы
• Сетевые и облачные сервисы безопасности
• Управление цифровыми рабочими местами
• ИИ и инфраструктура для AI/ML-нагрузок
• Частные и суверенные облака

В каталоге представлены и клиентские кейсы, и глубокие технические доклады, и стратегические обзоры от лидеров индустрии.

Навигация по каталогу: как найти нужные сессии

Слева на странице каталога расположена панель фильтров, которая помогает быстро ориентироваться в большом объёме контента. Доступны следующие категории:

• Search — строка поиска: используйте ключевые слова, названия продуктов или имена спикеров.
• Product — выбор по продуктам VMware: vSphere, NSX, Tanzu, Aria, Horizon, VCF и другие.
• Track — тематическое направление (например, Cloud Infrastructure, Modern Apps, Security, AI).
• Session Type — формат: breakout-сессии, hands-on labs, expert panels, theater sessions и т. д.
• Level — уровень сложности: от обзорных до продвинутых технических.
• Audience — целевая аудитория: архитекторы, DevOps-инженеры, администраторы, руководители и т. д.

Фильтры можно комбинировать, чтобы найти именно то, что соответствует вашим интересам и профессиональной роли.

Основные категории контента (Tracks)

Вот лишь некоторые ключевые направления, представленные в каталоге:

• Cloud Infrastructure & Operations — всё о построении и управлении облачными средами.
• Networking & Security — NSX, Zero Trust, микросегментация и защита облачных окружений.
• Modern Applications & DevOps — Tanzu, Kubernetes, CI/CD и автоматизация приложений.
• Innovation - технологии будущего и AI.

Почему стоит начать планирование сейчас

• Вы не пропустите ключевые сессии, некоторые из них идут параллельно — стоит выбрать приоритеты заранее.
• Можно собрать персонализированную программу - сессии можно добавлять в избранное и формировать собственный график.
• Удобно назначать встречи и демо - если вы планируете общение с инженерами VMware, клиентами или партнёрами — лучше сделать это заранее.

Затраты на память по-прежнему остаются одной из самых крупных статей расходов на серверную инфраструктуру, и при этом большая часть дорогой оперативной памяти (DRAM) используется неэффективно. А что, если вы могли бы удвоить плотность виртуальных машин и сократить совокупную стоимость владения до 40%?

С выходом VMware Cloud Foundation 9.0 технология Memory Tiering (многоуровневая организация памяти) делает это возможным. Команда инженеров VMware недавно представила результаты тестирования производительности, которые демонстрируют, как эта технология меняет экономику датацентров. Подробности — в новом исследовании: Memory Tiering Performance in VMware Cloud Foundation 9.0.

Ниже мы расскажем об основных результатах исследования, которые показывают, что Memory Tiering позволила увеличить плотность виртуальных машин в 2 раза при незначительном снижении производительности. Для получения полной информации о принципах работы Memory Tiering и более подробных данных о производительности, ознакомьтесь с полным текстом исследования.

Как Memory Tiering улучшает производительность датацентров и снижает затраты

В VMware Cloud Foundation 9.0 технология Memory Tiering предоставляет виртуальным машинам единое логическое адресное пространство памяти. Однако «под капотом» она управляет двумя уровнями памяти: Tier 0 (DRAM) и Tier 1 (Memory Tiering), в зависимости от активности памяти виртуальной машины. Фактически, система старается держать «горячую» (активную) память в DRAM, а «холодную» (неактивную) — на NVMe.

Со стороны виртуальной машины это выглядит как единое, увеличенное пространство памяти. В фоновом режиме гипервизор ESX динамически управляет размещением страниц памяти между двумя уровнями — DRAM и NVMe — обеспечивая при этом оптимальную производительность.

VMware провела тестирование на различных корпоративных нагрузках, чтобы подтвердить эффективность Memory Tiering. Были использованы серверы на базе процессоров Intel и AMD с различными конфигурациями DRAM. В VMware Cloud Foundation 9.0 по умолчанию используется соотношение DRAM к NVMe 1:1, и во всех тестах применялось именно оно.

Login Enterprise: Производительность виртуальных рабочих столов

Команда VMware использовала Login Enterprise для тестирования производительности VDI (виртуальных рабочих столов) в различных сценариях. Во всех тестах удалось удвоить количество виртуальных машин на хосте ESX при минимальном снижении производительности. Например, в конфигурации из трёх узлов vSAN:

• Удвоили количество VDI-сессий, которые могли выполняться на трёхузловом кластере vSAN — с 300 (только DRAM) до 600 (с использованием Memory Tiering).
• При этом не было зафиксировано потери производительности по сравнению с аналогичной конфигурацией, использующей только DRAM.

VMmark 3.1: производительность корпоративных приложений

Тест VMmark 3.1, включающий несколько нагрузок, имитирующих работу корпоративных приложений, показал отличные результаты:

• Конфигурация с Memory Tiering достигла 6 тайлов против 3 тайлов в конфигурации, использующей только DRAM. Это в 2 раза лучше.
• При сравнении конфигураций с 1 ТБ DRAM и с 1 ТБ Memory Tiering, снижение производительности составило всего 5%, несмотря на использование более медленной памяти NVMe в режиме Memory Tiering.

HammerDB и DVD Store: производительность баз данных

Производительность баз данных — один из самых ресурсоёмких тестов для любой инфраструктуры. VMware использовала HammerDB и DVD Store в качестве нагрузок для тестирования SQL Server, Oracle Database и MySQL. С помощью Memory Tiering удалось удвоить количество виртуальных машин при минимальном влиянии на производительность. Например, в тесте Oracle Database с нагрузкой DVD Store были получены следующие результаты:

• На хосте ESX с Memory Tiering удалось запустить 8 виртуальных машин против 4 в конфигурации, использующей только DRAM — плотность удвоилась.
• При сравнении конфигураций с 1 ТБ DRAM и с 1 ТБ Memory Tiering снижение производительности составило менее 5%.

Мониторинг Memory Tiering на хостах ESX

Для обеспечения высокой производительности при использовании Memory Tiering следует отслеживать два ключевых показателя:

• Поддерживайте активную память на уровне 50% или меньше от объёма DRAM — это обеспечит оптимальную производительность.

• Следите за задержкой чтения с NVMe-устройства. Наилучшая производительность достигается при задержке менее 200 микросекунд.

Преобразите экономику вашего датацентра

Memory Tiering предлагает новый подход к организации памяти:

• До 40% экономии совокупной стоимости владения (TCO) за счёт снижения требований к DRAM.
• Прозрачная работа — не требует изменений в приложениях или гостевых операционных системах.
• До 2-кратного увеличения плотности виртуальных машин для различных типов нагрузок.
• Гибкая инфраструктура, адаптирующаяся к изменяющимся требованиям рабочих нагрузок.

Memory Tiering уже доступна в VMware Cloud Foundation 9. Скачайте полное исследование производительности, чтобы подробнее ознакомиться с методологией тестирования, результатами и рекомендациями по внедрению.

Хотите попробовать Memory Tiering на практике?

Полноценный практический лабораторный курс предоставляет живую среду vSphere 9.0, где вы сможете изучить Memory Tiering и узнать, как использование NVMe-накопителей позволяет расширить и оптимизировать доступную память для хостов ESX.